On Wed, Nov 5, 2025, 14:30 Piotr P. Karwasz <[email protected]> wrote:
> 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. > You're confusing build maintenance and email box maintenance. TLDR. Gary > > 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] > >
