I haven’t attempted to do builds in a long time primarily because I haven’t had the time to figure out how it all works.
That said, I would prefer that the “primary” build not include this stuff. Once that build finishes have it kick off another job to run the tooling. This would mean that if they are configured in the pom.xml files that they be defined in a profile and the profile is not enabled for a normal build and only the profile runs in the extra build. Ralph > On Apr 30, 2026, at 6:17 AM, Gary Gregory <[email protected]> wrote: > > [+1] You can remove these features. > > I like to keep CI builds as simple as possible. I find the Log4j CI > unmaintainable due to its complexity. > > Gary > > On Thu, Apr 30, 2026 at 9:10 AM Volkan Yazıcı <[email protected]> wrote: >> >> Log4j's CI pipeline is broken because of Develocity[1], Scorecards[2], and >> Rulesets[3], all of which Piotr introduced. Failures caused by these >> components render the CI broken several times every year and >> require constant fixing. *Currently, we cannot merge any Log4j changes or >> make releases.* I find this very concerning, something that needs to be >> addressed. >> >> I'm tired of fixing CI due to components nobody uses, except Piotr. I >> propose removing them: >> >> apache/logging-parent#467 >> <https://github.com/apache/logging-parent/pull/467> >> apache/logging-parent#468 >> <https://github.com/apache/logging-parent/pull/468> >> apache/logging-log4j2#4108 >> <https://github.com/apache/logging-log4j2/pull/4108> >> >> Piotr proposes fixing them yet another time: >> >> apache/logging-parent#469 >> <https://github.com/apache/logging-parent/pull/469> >> apache/logging-log4j2#4107 >> <https://github.com/apache/logging-log4j2/pull/4107> >> >> Would other PMC members mind weighing in as a tie-breaker, please? >> >> [+1] You can remove these features. >> [-1] Don't remove them, because... *AND I VOLUNTEER TO MAINTAIN THEM.* >> >> --- >> >> [1] Gradle Develocity is a proprietary product to which ASF was given free >> access. CI publishes build reports there, and Develocity gives us a >> dashboard with statistics. This is facilitated by the `gradle/develocity` >> GitHub Action (GHA). Since it is not an INFRA-approved GHA, every single >> new version needs to be whitelisted by INFRA >> <https://github.com/apache/infrastructure-actions/blob/main/actions.yml>. >> As a result, it regularly breaks the CI. >> >> [2] OpenSSF Scorecards is facilitated by `ossf/scorecard-action` GHA, and >> every version needs to be whitelisted by INFRA just like >> `gradle/develocity`. Same problem. I've been fighting with >> Scorecards-related CI issues for *4 years*, and I am done with it. >> >> [3] Rulesets is a recently introduced `.asf.yaml` feature >> <https://github.com/apache/infrastructure-asfyaml#rulesets>, and it is not >> battle-tested. See apache/infrastructure-asfyaml#93 >> <https://github.com/apache/infrastructure-asfyaml/pull/93>. We cannot even >> remove this feature anymore. >> <https://github.com/apache/logging-parent/pull/467#discussion_r3167440766> >> Also >> see INFRA-27873 <https://issues.apache.org/jira/browse/INFRA-27873>. I am >> very frustrated to see very established and crucial projects like Log4j >> used as a pilot for these kinds of experiments.
