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<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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7979&data=05%7C02%7CJinwoo.Hwang%40sas.com%7Ce95f6986d8304da0e8ed08de55d3ea47%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639042565837926717%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DZiFzd99ufQBpC9uQTxHpluSBZz5oxJG0%2FuN6cBR2UI%3D&reserved=0<https://github.com/apache/geode/pull/7979> • https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7978&data=05%7C02%7CJinwoo.Hwang%40sas.com%7Ce95f6986d8304da0e8ed08de55d3ea47%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639042565837939661%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Dl4o4e8Zz88xIQogBoqT76guSOz%2BqNqMeKM%2BWZwONzY%3D&reserved=0<https://github.com/apache/geode/pull/7978> • https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7977&data=05%7C02%7CJinwoo.Hwang%40sas.com%7Ce95f6986d8304da0e8ed08de55d3ea47%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639042565837949355%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JsXHAAxH9qsBBtUzzIuyLPBM5qqGOrelvkSVkftYZQ0%3D&reserved=0<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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7980&data=05%7C02%7CJinwoo.Hwang%40sas.com%7Ce95f6986d8304da0e8ed08de55d3ea47%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639042565837956972%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mo84dt%2BbVLW2JpCcwC7Jjo%2B3Zj85Qd7xm0lKYYJ8G14%3D&reserved=0<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
