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. 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] > >
