On Fri, Apr 17, 2026 at 10:24 AM Alex Herbert <[email protected]> wrote: > > On Fri, 17 Apr 2026 at 15:07, Gary Gregory <[email protected]> wrote: > > > This creates more complexity and delegation than is required to keep a > > maintainer's life simple (at least mine). > > > > If I want or need a new version of that GitHub action, I need to update the > > parent repo, release it, migrate to it. That's what we do for Maven builds > > of course, but adding GitHub actions to the mix is a bridge too far for me. > > > > Is a release of commons parent required?
If you're not using a specific version, then you are depending on a snapshot? > > The example of how to use this workflow is: > > uses: > apache/commons-parent/.github/workflows/codeql-analysis-reusable.yml@master > > The pin is not to a specific version but to the master branch. That's even worse: How does this provide anything deterministic? We want more precision, not less. Gary >From the > github docs [1] I cannot determine if this means derived workflows just use > the current public repo version, or if there is a release process to set > the 'master'. > > Alex > > [1] > https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsuses > > > > If this is going in the direction of Log4j, then it's going to be a real > > problem in the long term: that integration with GitHub actions is so deep > > and complicated, I've given up trying to understand it. > > > > This also raises the barrier to entry IMO, you need to know Java of course, > > and Maven sure, but heaven forbid if something goes wrong with GitHub > > actions... > > > > Gary > > > > On Fri, Apr 17, 2026, 09:18 Piotr P. Karwasz <[email protected]> > > wrote: > > > > > Hi all, > > > > > > As a follow-up to the November discussion [1], I have opened two PRs to > > > introduce reusable workflows for CodeQL and Scorecards: > > > > > > - https://github.com/apache/commons-parent/pull/699 > > > - https://github.com/apache/commons-parent/pull/700 > > > > > > The main concern raised (notably by Gary) is that the added indirection > > > makes projects harder to maintain. I respectfully disagree: these > > > workflows are essentially maintenance-free, they only change when > > > dependencies are upgraded, and they rarely fail for reasons unrelated to > > > the project itself (e.g. a compilation error). > > > > > > Rather than a project-wide rollout, I propose a limited trial: adopt the > > > reusable workflows in two or three projects, evaluate the experience, > > > and either extend to all projects or revert to the status quo. > > > > > > I am happy to monitor these workflows and address any issues that arise. > > > My expectation is that they will go unnoticed. > > > > > > Thoughts? > > > > > > Piotr > > > > > > [1] https://lists.apache.org/thread/rnb8j9og60j4rs0pr1fljlvbpy2zf1tt > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
