Hi Gary, On 5.11.2025 16:40, Gary Gregory 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_.
It should make maintenance easier: you don't get 40 Dependabot PRs for each action upgrade in 40 repositories, but just a single PR. The workflows would still be in a single file, just not in the same repository. Personally I don't look at workflow files too often, so it should not be a problem to look into another repo from time to time. > 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. I copied the part about the PMD from commons-compress#724 [1] and I think the details of the PoC can be discussed further in commons-parent#681 [2]. My main point here is to highlight how reusable workflows make these kinds of decisions much easier. Instead of adding a new Java version to 40 separate workflow files every six months, we can update it once in a single shared workflow. > 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. Sure, there are differences between the GitHub workflows, but they don’t always reflect real requirements of each repository. In many cases, those workflows simply weren’t updated in sync with others. Workflows like CodeQL (for GitHub Actions and Java), Dependency Review, and Scorecards *should* be universal. I agree that the Maven workflow may need some project-specific tweaks, but by using a reusable workflow we can ensure that build parameters come from a consistent, well-defined set of sources. For example, if special parameters are needed, we can agree, and document, that they should be provided: - either in `.mvn/maven.config` and `.mvn/jvm.config`, which also benefits local builds, - or via `MAVEN_ARGS` and `MAVEN_OPTS`, but not both. > 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. The `dependabot@` mailing list won’t eliminate all the “noise” from Dependabot activity: it only receives messages caused by Dependabot, not the human interactions that follow. Even setting that aside, the time you (and others) spend handling Dependabot PRs manually could be used much more effectively. I’d rather see your expertise applied to improving our code and infrastructure than to clicking “Merge” on routine updates. Piotr [1] https://github.com/apache/commons-compress/pull/724 [2] https://github.com/apache/commons-parent/pull/681 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
