Increase test processes to start in parallel #2953
Conversation
| tasks.withType<Test>().configureEach { | ||
| useJUnitPlatform() | ||
|
|
||
| maxParallelForks = if (System.getenv("CI") != null) { |
There was a problem hiding this comment.
Or we can read dokka_integration_test_parallelism like
There was a problem hiding this comment.
There are more cores in TeamCity runners, maybe we can use
maxParallelForks = if (System.getenv("GITHUB_ACTIONS") != null) {
Runtime.getRuntime().availableProcessors()
} else {
(Runtime.getRuntime().availableProcessors() / 2).takeIf { it > 0 } ?: 1
}for both tests and integrationTests, get rid of dokka_integration_test_parallelism property.
|
Finally set out some time to test it. I think it makes perfect sense to do this for unit tests, absolutely no questions here. But I wasn't sure what sort of an impact it would have on our integration tests. I have a totally overspec'd workstation (16C, 32T, 128GB RAM) to draw any conclusions, but running the
I actually wonder what would happen if I didn't have enough memory - would the integration tests fail, or would the time increase drastically because of GC problems? I'm trying to trigger integration tests on teamcity for this PR, but teamcity is not picking up the branch changes like it did before... Our admins might've introduced some security policies, so I'll have to resolve that first, which might take time... I'd be happy to merge this change for unit tests only though, if you open a separate PR or change this one |
c3159f0 to
c9f4aed
Compare
|
(looks like TeamCity was simply lagging yesterday, integration tests work now) |
There was a problem hiding this comment.
Thank you!
I'm still interested in having (or at least testing) this change for integration tests, so @Goooler if you want and have the time, feel free to open a separate PR :)
More context see detekt/detekt#5944.
https://docs.gradle.org/7.6/userguide/performance.html#execute_tests_in_parallel