Wiki source code of Build Optimization
Last modified by Thomas Mortagne on 2025/11/06 09:36
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | The idea of this design page is to gather idea to improve builds of XWiki primarily to speed up CI builds. Of course ideas put there could also be used to speed up local builds. | ||
| 2 | |||
| 3 | Quick thoughts to be discussed: | ||
| 4 | |||
| 5 | == Do less == | ||
| 6 | |||
| 7 | * try to only build modules that have been impacted by a change (imply mono repo?) | ||
| 8 | * try to fail the build faster: if there's a compilation failure in one job, it doesn't worth executing other ones at all for example | ||
| 9 | * maybe execute some tasks only periodically (e.g. coverage checks might not be needed at every build?) | ||
| 10 | * some Maven plugins are executed all the time, but sometimes it would be enough to check some things only in the WAR and the flavor modules for example (for example forbidden dependencies and some other enforcer related checks) | ||
| 11 | * Docker tests collect flickering tests from all already executed tests. This can easily take 10 minutes just for the post build scripts if there are a lot of failing tests (> 60?). This could be improved by | ||
| 12 | ** not collecting all flickering tests again | ||
| 13 | ** optimizing the code for that - no step seems particularly slow, but still each takes its time | ||
| 14 | ** combining several docker test modules into a single Jenkins build job - we're getting more and more small docker test modules and each having their own Jenkins job seems wasteful. This could possibly also benefit from caching artifacts between executing the two test modules. | ||
| 15 | |||
| 16 | == Memory == | ||
| 17 | |||
| 18 | * find memory leaks | ||
| 19 | ** build xwiki-platform with a much lower memory than the current CI (for example 512MB) | ||
| 20 | ** analyze the produce OOM memory dump to find what does not make sense | ||
| 21 | ** fix what does not make sense | ||
| 22 | ** repeat | ||
| 23 | |||
| 24 | == Speed == | ||
| 25 | |||
| 26 | * in many tests the setup is done using the UI but relying on the REST API would be way faster (and less fragile) |
