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
