OK, I have no issue with running tools that provide useful information. But I would prefer they not be tied to release builds that prevent them from succeeding.
Ralph > On Apr 30, 2026, at 10:48 AM, Piotr P. Karwasz <[email protected]> > wrote: > > Hi Ralph, > > On 30.04.2026 18:48, Ralph Goers wrote: >> Piotr - How do they integrate with the build? Are they separate >> workflows in GitHub? How exactly do they break builds? If they are >> part of the Maven build can we separate them into a separate job? > > > Features that can run in separate jobs already do. > > ## Develocity (Maven Extension) > > Develocity is a proprietary Gradle Inc. *core* extension that > instruments the build with metrics like flaky and failed test tracking: > > https://develocity.apache.org/scans?search.relativeStartTime=P90D&search.rootProjectNames=Apache%20Log4j%20BOM > > As a *core* extension, it isn't configured in `pom.xml` but added to > `.mvn/extensions.xml` by the `build-reusable` workflow. > > Aside from being proprietary, shading OSS dependencies, and being > intentionally obfuscated, we've only hit one issue: after an upgrade, > builds using `-Dmaven.test.skip` (instead of `-DskipTests`) failed. > > I'd like to keep it running on CI to track flaky tests, since they > rarely flake on our own hardware. > > ## Develocity (GitHub Action) > > On CI, Develocity can't publish results for *pull requests*: PRs have no > access to secrets, hence no API key. > > The Gradle team's workaround is `gradle/develocity-actions`, which > stores results as a workflow artifact and pushes them via a subsequent > `workflow_run`. This is what currently blocks builds: we use a version > no longer on the INFRA whitelist. > > Since I mainly care about flakes on the main branch, I don't mind > dropping this action. But let's avoid sudden large changes to > `reusable-build`: the simplest fix is upgrading to a whitelisted version. > > Other steps in `reusable-build` could be cut since they have separate > workflows: > > - Reproducibility verification > - Site generation > > This would simplify the build to just checkout/install JDK/run Maven. > > ## Scorecards > > Scorecards is collateral damage in Volkan's PR. It is *not* among the > actions causing build failures: > > "The actions gradle/develocity-actions/setup-maven@4a2aed8…, > gradle/actions/setup-gradle@017a9ef…, and graalvm/setup-graalvm@7f488cf… > are not allowed in apache/logging-log4j2 because all actions must be > from a repository owned by your enterprise, created by GitHub, or match > one of the patterns: ..." > > It's entirely separate from the build, running probes on the repo to > check some admittedly arbitrary best practices. Volkan disabled > `scorecards-analysis` two years ago; the reusable version was just a > leftover. > > Whether to keep it deserves a separate thread. We don't strictly need to > run it (any GitHub user can), but only our repo workflows can publish to > the official site: > > https://securityscorecards.dev/viewer/?uri=github.com/apache/logging-log4j2 > > Piotr
