the release / build CI job has grown from ~2h (on 16-CPU SAP runners) to ~4h on the current ubuntu-latest (2-CPU) runners. the root cause is not a single regression but a combination of factors that compound badly at low CPU counts
so, the main monsters are:
com.sap.sailing.gwt.ui (GWT compile) - 42 min
com.sap.sailing.server.trackfiles.test - 1h 15 min
com.sap.sailing.selenium.test (all packages) -1h 15 min
Other tests and compilation - 50 min
here are the problems that were identified:
-
No Maven/Gradle dependency caching in CI
Every run re-downloads the entire ~/.m2/repository including all Tycho p2 artifacts from scratch.
waste: 20 min per run
-
trackfiles.test takes 1h 15min for only 23 tests the module has 9 test classes, each spawning its own OSGi JVM (via Tycho Surefire). On 2 CPUs these forks run sequentially. Each fork pays the full OSGi container startup/shutdown cost (~3–8 min). The test logic itself is fast.
-
Selenium takes ~74 min. The selenium packages run sequentially: usermanagement alone is 23 min (15 tests), raceboard 11 min,
adminconsole 10 min. no parallelism between test classes; each likely recreates browser state per class
-
GWT compile is pure CPU bottleneck. gwt.ui at 42 min with 4 workers on 2 CPUs
-
all of this runs in a single CI job. GWT compile, all tests, Android build, and release packaging are one sequential job. there is no parallelism
at the CI level either
so, the logical steps to solve this issue is to try doing the following
1.add Maven + Gradle cache (will save 20 minutes)
2.split CI into parallel jobs (will save around 1,5 hours)
3.Tycho enabling (I need to research more on that but it can save a lot)
another problem is selenium tests where the solutions could be optimizing the parallelism and wait times but this is a topic for the whole separated bug. so, for now, the idea is to make and test small changes in order to be sure that they do not cause broken dependencies or lack of some data while parallelizing them all
the release / build CI job has grown from ~2h (on 16-CPU SAP runners) to ~4h on the current ubuntu-latest (2-CPU) runners. the root cause is not a single regression but a combination of factors that compound badly at low CPU counts
so, the main monsters are:
com.sap.sailing.gwt.ui (GWT compile) - 42 min
com.sap.sailing.server.trackfiles.test - 1h 15 min
com.sap.sailing.selenium.test (all packages) -1h 15 min
Other tests and compilation - 50 min
here are the problems that were identified:
No Maven/Gradle dependency caching in CI
Every run re-downloads the entire ~/.m2/repository including all Tycho p2 artifacts from scratch.
waste: 20 min per run
trackfiles.test takes 1h 15min for only 23 tests the module has 9 test classes, each spawning its own OSGi JVM (via Tycho Surefire). On 2 CPUs these forks run sequentially. Each fork pays the full OSGi container startup/shutdown cost (~3–8 min). The test logic itself is fast.
Selenium takes ~74 min. The selenium packages run sequentially: usermanagement alone is 23 min (15 tests), raceboard 11 min,
adminconsole 10 min. no parallelism between test classes; each likely recreates browser state per class
GWT compile is pure CPU bottleneck. gwt.ui at 42 min with 4 workers on 2 CPUs
all of this runs in a single CI job. GWT compile, all tests, Android build, and release packaging are one sequential job. there is no parallelism
at the CI level either
so, the logical steps to solve this issue is to try doing the following
1.add Maven + Gradle cache (will save 20 minutes)
2.split CI into parallel jobs (will save around 1,5 hours)
3.Tycho enabling (I need to research more on that but it can save a lot)
another problem is selenium tests where the solutions could be optimizing the parallelism and wait times but this is a topic for the whole separated bug. so, for now, the idea is to make and test small changes in order to be sure that they do not cause broken dependencies or lack of some data while parallelizing them all