davsclaus opened a new pull request, #28004: URL: https://github.com/apache/camel/pull/28004
[CAMEL-25720](https://issues.apache.org/jira/browse/CAMEL-25720): **run the tests of camel-jbang-core in parallel forks.** ### The problem The tests of camel-jbang-core ran one JVM per test class, one class at a time (`forkCount=1`, `reuseForks=false`). AurĂ©lien noted that in a `-T1C` build on Jenkins they take almost 20% of the time, almost alone, as the module comes late in the build. Half of the 297 classes run in less than 0.5 seconds, so most of the time went into starting JVMs. ### Why they did not run in parallel - `dsl/pom.xml` turns on JUnit class concurrency (`camel.surefire.parallel=true`), so a reused JVM would run the classes at the same time, while the CLI keeps the home directory in a static field (`CommandLineHelper.useHomeDir`). - Forks share the file system: the fixed homes of the tests (`target`, `target/test-action`, `target/test-process`, ...), the working directory of the module (`camel run` deletes `.camel-jbang`, `camel export` builds in `.camel-jbang/work`, `camel init` writes its file there, a local `camel-cli.properties`) and port 2121 of the ftp service of `camel infra run`. - A test that set no home used the `~/.camel` of the developer. ### The change - 4 reused forks, with no JUnit concurrency inside a fork. - Each fork has a home of its own (`user.home` is `target/test-home-<fork>`), and the local Maven repository stays the build's. - `CamelCommandBaseTestSupport.useTestHomeDir()` gives a test a temporary home and restores the previous home after the test. The action, process, infra, logger, startup recorder, plugin, config and version tests use it instead of their fixed homes. `UserConfigHelper` writes the user configuration in the home of the test, and refuses to write it in the user home. - The tests that use the working directory (`@UsesWorkingDirectory`: export, dependency, transform, init, load, eval, a route action on a Java source, and the config tests) or a fixed port (`@UsesFixedPort`: 2 infra tests) run after the others, one class at a time, in a fork of their own (the `serial-test` execution). To find them, every class was run with a listener that compared the module directory before and after it. The config and init tests create and delete their files within a test, so they were added by reading them. - LoadTest and EvalSimpleTest point at the home that their Camel uses: the routes of LoadTest run in this JVM, and EvalSimpleTest starts the Camel installed with JBang. PluginHelperTest restores the home it changes. ### Result Surefire time of the module, locally (14 cores, JDK 25): | | Time | |---|---| | before: a JVM per test class | 399 s | | after: 2260 tests in 4 forks, then 237 serial | 153 s (27 s + 126 s) | ExportTest takes 95 of the 126 seconds of the serial part; the follow-up PR for the kamelet catalog and the Quarkus BOM makes it 44 seconds. The number of forks is the property `camel.surefire.forkCount`: `-Dcamel.surefire.forkCount=8` runs the parallel part in 24 seconds instead of 27. ### Depends on #28003 In reused JVMs, a `DefaultCamelContext` started by a test could fail with a `ConcurrentModificationException` in `DefaultBeanIntrospection` (about one run out of six), a race with the camel-cli-connector that every `camel run` can hit too. #28003 (CAMEL-25734) fixes it, so this PR should go in after it. ### Tests `mvn verify` of camel-jbang-core: all pass. With the fix of #28003, the parallel part passed 15 runs out of 15 with 8 forks. _Claude Code on behalf of davsclaus_ đŸ¤– Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01DDRLJAyf8cDXSg8iX785My -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
