2 ms·

Try the flag -T XC where X is the number of threads you want (similar to make -jX)

• noisy_boy 7y ago
  Yeah - I did try it + the other oft-recommended optimizations. I have arrived at the conclusion that the actual build is not taking the majority of the overall build time, it is the various before and after that happens (e.g. checkout git repo, deciding build parameters, sonar qube scans, creating git tags and so on). Since the Jenkins pipeline basically runs shell scripts to do these things in each stage, the overall build just feels slow. Collapsing the stages would make things more messy, keeping them separate is cleaner but means more per-stage overhead.
  • mister_hn 7y ago
    I would suggest to keep the shell scripts calls to the minimum (e.g. compact commands together if possible). You can still have nice stages separations, but try to avoid the pitfall of doing too much shell invocations. A good trick is to create a fake "multi-module reactor" pom.xml and grouping all the modules logically there, then you build like mvn clean install -f reactor-pom.xml -T 8C
    • noisy_boy 7y ago
      Thanks for the suggestions. We have very few multi-module projects. Most of the time, the time is spent in the various stages - almost all of them shell scripts. I guess there is overhead of initializing the stages/spawning etc. I also think that Jenkins could be doing some serialization to be able to resume a failed build - which we don't really need as we'll probably start a fresh build anyway. That's my next area to explore.