[2024-05-21T20:30:08.150Z] BUILD SUCCESSFUL in 2h 17m 22s
[2024-05-21T20:30:08.150Z] 321 actionable tasks: 119 executed, 202 up-to-date

almost speedup 50% 😄

It's hard to tell for sure. The load on Jenkins varies a lot, so this is a top 30th percentile build, not too out of the ordinary.
If running this build under low load can beat 1h5m (5th percentile) I would confidently say it's better. I need some more runs.

Take a look at this graph:

This PR isn't any of the short bars on this graph, it's 5/5 of the tallest bars. This is a serial execution graph, so measuring the total time taken multiplied by the parallelism, roughly. That means despite maybe saving some overall execution time, running the tests at high parallelism wasted a lot of time, waiting for the CPU or whatever else.

Here's some total task times across some different builds:

The 30minute compile and 4h spotbugs are very strange to me, plus just to cherry-pick from the build:

:streams:upgrade-system-tests-36:test | 1h 35m 50.821s

There's no tests in this package! it took junit 95 minutes to scan the classes and not find any tests??!

And i don't even know what this line means, because it can't mean it took 28 minutes for gradle to determine the task was up to date, right?

:streams:upgrade-system-tests-37:compileTestJava UP-TO-DATE | 28m 52.150s

I think all of the above is only consistent with an extremely overloaded test runner.

It looks like 2 (or perhaps 3 or 4) is appropriate for the current CI conditions. I don't see any substantial difference that would make this a worthwhile change for us, or worth the risk of being worse CI neighbors than we already are.