Another level of delegation just to build on GH CI is a complication I have no need for, YMMV. I don't see how this makes building better or easier.
Seeing the GH CI build in one small file is straight forward and _easy to understand_. >From what I see, all components should ignore this maven configuration because it doesn't serve the need of any component. All components build on Java 26-ea as an experimental build. This configuration explicitly turns this off because... PMD doesn't support Java 26 yet? Not only is PMD not used by all default Maven goals but this is how we find out what's working in our stuff and in the FOSS ecosystem at large. We can then give feedback. Which I do. We have many components that have a special tweak to their GH CI configuration like setting this or that command line argument. We have others that are a complex world of their own. Trying to create reuse in GH CI just makes it even _more_ complex _and_ harder to debug builds than they already are. Debugging a CI build on GH doesn't happen often but it's never simple. Adding another layer doesn't make it easier. After much delay, we finally have a dependabot email list, so the "noise" argument is moot IMO. We should only make the GH CI builds more complex if we must IMO. Huh, Gary On Wed, Nov 5, 2025, 06:24 Piotr P. Karwasz <[email protected]> wrote: > > Hi all, > > Maintaining CI workflows across more than 40 Commons repositories > creates significant maintenance overhead and Dependabot noise. > I’d like to propose refactoring our four common workflows, CodeQL > Analysis, Dependency Review, Java CI, and Scorecards Analysis, > to use reusable workflows defined in `commons-parent` instead. > > As an example, I’ve opened commons-parent#681 [1], which refactors > maven.yml, and triggered a demo run in commons-lang [2]. If there’s > agreement, I can refactor the remaining three workflows as well. > > Adopting shared workflows raises the question of how they should be > updated across projects. Some existing approaches in Apache projects > include: > > 1. Pinning to a commit (SHA-1): reliable but reintroduces Dependabot > churn. > 2. Pinning to release tags: used by the Logging Services PMC. Updates > happen with parent releases, useful if workflow and POM changes must > align. > 3. Branch-based sharing: used by the Maven PMC in > `maven-gh-actions-shared` [3], where branches correspond to workflow > major versions. > > To start simple, I suggest we reference the master branch of > commons-parent. This provides automatic propagation of workflow > improvements with zero maintenance effort in downstream repositories. > > What do you think? > > Piotr > > [1] https://github.com/apache/commons-parent/pull/681 > [2] https://github.com/apache/commons-lang/actions/runs/19098960862 > [3] https://github.com/apache/maven-gh-actions-shared > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
