Hi Geode Development Community,
Following the recent discussion on GEODE-10550 and Sai's successful
implementation of GitHub Actions workflows for the support/1.15 branch, I'd
like to propose extending the same automated CI/CD capabilities to the
support/2.0 branch.
Background
As discussed in the recent thread about support/1.15, the support branches
currently lack automated testing and security scanning for pull requests. This
creates risk when accepting dependency updates, security fixes, and other
maintenance changes. The community consensus was that we should adopt this
pattern across all supported maintenance branches.
Current State
The support/2.0 branch already has GitHub Actions workflow files
(.github/workflows/codeql.yml and .github/workflows/gradle.yml), but they are
configured to trigger on the "develop" branch instead of "support/2.0". This
means:
• PRs targeting support/2.0 receive no automated validation
• Dependency updates and security fixes lack CI verification
• No automated security scanning via CodeQL
Proposal
Update the existing workflow files on support/2.0 to trigger on the correct
branch, enabling the same comprehensive CI/CD checks that run on develop:
1. gradle.yml - Complete build and test suite:
• Build verification with code quality checks (spotlessCheck, rat,
checkPom, pmdMain)
• Java API compatibility checks (japicmp)
• Unit, integration, and acceptance tests
• Distributed tests for all modules (WAN, CQ, Lucene, Management, Assembly)
2. codeql.yml - Security scanning:
• CodeQL analysis for Go, Java, JavaScript, and Python
• Weekly scheduled security scans (Tuesdays at 22:22 UTC)
Key Differences from support/1.15
• Java Version: support/2.0 uses Java 17 (not Java 8 like support/1.15)
• The workflow files already exist with correct Java 17 configuration
• Only the branch trigger configuration needs updating
Implementation
I've prepared the following:
• PR #[7981]: https://github.com/apache/geode/pull/7981
• Branch: https://github.com/JinwooHwang/geode/tree/feature/GEODE-10551
• JIRA: GEODE-10551
The changes are minimal - updating branch references from "develop" to
"support/2.0" in both workflow files.
Rationale
As I mentioned in response to Sai's support/1.15 proposal, I believe this
pattern should be adopted across all supported maintenance branches. The
support/2.0 branch is actively maintained and expected to receive dependency
updates and security fixes. Without automated testing:
• We risk introducing regressions in maintenance releases
• Security vulnerabilities may go undetected
• Release candidates lack the same validation as develop branch
• Contributors and reviewers have less confidence in changes
The risk profile of support branches and release candidates justifies
comprehensive CI coverage. This is especially important as we prepare release
artifacts that will be used in production environments.
Request for Feedback
I'm seeking community feedback on this proposal:
1. Do you agree that support/2.0 should have the same CI/CD capabilities as
develop?
2. Should we run the full test suite (including distributed tests) or a
subset?
3. Are there any concerns with the proposed implementation?
If there are no objections, I'll proceed with updating the JIRA ticket and the
PR. Following validation on support/2.0, we should consider enabling these
workflows for any other active support branches and for release candidate
branches as well.
I appreciate Sai’s initiative on this effort, which aligns perfectly with our
2026 roadmap for CI/CD pipeline upgrades, and I look forward to the community’s
feedback.
Best regards,
Jinwoo Hwang (he/him/his)
SAS® Research and Development
http://JinwooHwang.com<http://jinwoohwang.com/>
From: Jinwoo Hwang via dev <[email protected]>
Date: Saturday, January 17, 2026 at 10:24 AM
To: [email protected] <[email protected]>
Cc: Jinwoo Hwang <[email protected]>
Subject: Re: [PROPOSAL] Enable GitHub Actions CI/CD for support/1.15 branch
EXTERNAL
Hi Sai,
First of all, I appreciate you taking the time to review the PRs. Thank you for
putting this together and for proactively addressing the CI and security gaps
on the support/1.15 branch. I realized that GitHub Actions were not enabled for
support branches in the same way as the develop branch, which had been a
concern for me, and I’m grateful that you took the initiative to resolve this
issue—especially in response to the recent PRs I submitted to support/1.15 for
dependency updates and security fixes.
I agree with the core concern: given that we are actively accepting changes on
support/1.15, including dependency bumps and vulnerability remediations, the
absence of automated testing and scanning increases the risk of regressions and
missed issues. I was also not comfortable with the absence of GitHub Actions
while preparing release candidates, as they should receive the same level of
validation and confidence as develop branch.
The proposal to reuse the existing GitHub Actions workflows from develop, with
appropriate adjustments (notably Java 8 and the Gradle 6.8.3 constraints),
seems reasonable and well thought out. I also appreciate that you’ve already
prepared PR #7980 and linked it to GEODE-10550, which makes the review concrete.
More broadly, I think this is a pattern we should adopt across all supported
maintenance branches. Once validated on support/1.15, we should plan to expand
the same CI and security workflows to other active support branches, especially
support/2.0. In addition, we should enable these workflows for release
candidate branches so that candidates receive the same level of testing and
security scrutiny prior to a formal release.
Regarding test scope, my preference would be to run the full test
suite—including distributed and acceptance tests—to ensure rigorous quality
control and avoid surprises in maintenance and release artifacts. While I
understand the cost and runtime considerations, the risk profile of support
branches and release candidates justifies comprehensive coverage.
I encourage others to review the PR and share feedback. Assuming there are no
strong objections or overlooked concerns, I would be supportive of moving
forward with this change.
Thanks again for driving this initiative.
Best regards,
Jinwoo Hwang (he/him/his)
SAS® Research and Development
http://JinwooHwang.com
From: Sai Boorlagadda <[email protected]>
Date: Saturday, January 17, 2026 at 9:23 AM
To: [email protected] <[email protected]>
Subject: [PROPOSAL] Enable GitHub Actions CI/CD for support/1.15 branch
EXTERNAL
Hi Geode Community,
I'd like to propose enabling GitHub Actions workflows for the support/1.15
branch to ensure automated testing and security scanning for maintenance
releases. Over the past week, several PRs have been submitted to this
branch for dependency updates and security fixes, but currently there are
no automated CI/CD checks running on these PRs.
Recent PRs to support/1.15 (examples):
• https://github.com/apache/geode/pull/7979
• https://github.com/apache/geode/pull/7978
• https://github.com/apache/geode/pull/7977
• These PRs include dependency bumps and security vulnerability fixes
• Without automated testing, we risk introducing regressions or
missing issues
Proposal
Enable the same GitHub Actions workflows that run on the develop branch to
also run on support/1.15:
1. gradle.yml - Comprehensive build and test suite:
• Build verification with code quality checks (spotlessCheck, rat,
checkPom, pmdMain)
• Java API compatibility checks (japicmp)
• Unit, integration, and acceptance tests
• Distributed tests for all modules (WAN, CQ, Lucene, Management,
Assembly)
2. codeql.yml - Security scanning:
• CodeQL analysis for Go, Java, JavaScript, and Python
• Weekly scheduled security scans
I've prepared PR #7980 with the necessary workflow configurations:
• PR:https://github.com/apache/geode/pull/7980
• JIRA: GEODE-10550
The workflows are configured to use Java 8 (matching the support/1.15
branch requirements with Gradle 6.8.3) rather than Java 17 used on develop.
Request for Feedback. Let's discuss if we collectively think we should run
the pipelines on the support branch? if we conclude yes, then I request
your approval on the PR #7980.
We can also discuss if we should run all tests are few categories. I'll
wait for community feedback before merging. If there are no objections,
I'll proceed with the merge.
Thanks,
Sai
