On 2024/06/14 20:37:44 "Piotr P. Karwasz" wrote:
> Hi Gary,
>
> On Fri, 14 Jun 2024 at 18:12, Gary Gregory <garydgreg...@gmail.com> wrote:
> > I sure hope that all tests are ALWAYS run by default in the 2.x branch,
> > otherwise it will be a -1 from me.
>
> Currently Predictive Test Selection is enabled on all CI builds,
> except the `release/*` branches, since I am trying to evaluate the
> feature, before I make a proposal on this mailing list. So please,
> indulge me, for a couple of weeks.
>
> Currently the usage of Develocity is experimental and `logging-log4j2`
> is running builds using the `develocity` branch of `logging-parent`,
> so be reassured that before we do any release:
>
> 1. We'll largely discuss my findings (PMC meeting in a week or two?),
> 2. `logging-parent` needs to be released.
>
> For those that have never heard about Develocity, it is a new Gradle
> product that aims at increasing developer productivity by reducing the
> time we wait for our builds to complete.
> INFRA rolled out an ASF instance of Develocity and you can check it out at:
>
>
> https://ge.apache.org/scans?search.rootProjectNames=*log4j*&search.timeZoneId=Europe%2FWarsaw#
>
> I am experimenting with this tool to improve the quality of our test
> suites (aka the code users never help us with). It has some useful
> features like:
>
> 1. Test execution statistics, which help us identify the broken and
> flaky tests. As it turns out `JeroMqAppenderTest` is not the test that
> fails most often and we also have flaky tests that never (as far as I
> can remember) caused a build to fail. For example `BurstFilterTest`
> fails at least once in 50% of the builds.
> 2. PTS will allow our CI to run faster, because it only runs the tests
> that are more likely to fail for a given code modification. This might
> help contributors that submit PRs to get faster feedback or run the
> test suite before submitting a patch.
> Truth be told, I often skipped the local test run, since it took over
> 30 minutes on my old laptop. On my new desktop I always run all tests,
> since it takes 3 minutes (half of that time Maven is waiting for the 3
> broken Flume tests).
>
> Of course I have my reservation regarding this tool:
>
> 1. The Maven plugin it uses is not Open Source. It is probably high
> quality code, but not **provably** high quality code.
> 2. It uses build caching, which might fake the results of builds.
>
> As far as I understand Develocity should be a no-op on your computers,
> unless you generate an API key for it. If you want to try it, run:
>
> ./mvnw com.gradle:develocity-maven-extension:provision-access-key
>
> in a working tree of `logging-log4j2`.
What does that mean, "in a working tree of `logging-log4j2`"?
I am -1 on changing our PRODUCTION 2.x build. If you want to experiment with
some company's product, please do so in a non-production branch. The cynic in
me sees this as a company wanting free advertising to say Apache uses their foo
product in production.
> 1. The Maven plugin it uses is not Open Source. It is probably high
> quality code, but not **provably** high quality code.
> 2. It uses build caching, which might fake the results of builds.
Well, that sounds horrible: "which might fake the results of builds."
Gary
>
> Piotr
>
