I am fully onboard with keeping 2.0 as healthy as possible and turn on GitHub Actions for 2.0 to make sure we are running code analysis with tests.
My opinion for the test suite would be to run the tests are stable while keeping the coverage as high as possible. Best regards, Mark On Mon, Jan 19, 2026 at 3:33 AM Jinwoo Hwang via dev <[email protected]> wrote: > 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 >
