On Wed, 5 Nov 2025 at 15:40, Gary Gregory <[email protected]> wrote: > > 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.
Agreed. > After much delay, we finally have a dependabot email list, so the "noise" > argument is moot IMO. That remains to be seen; it's not currently possible to direct Dependabot commit emails to the new list. > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
