Hi, On Sun, Jul 31, 2016 at 3:09 AM, khmarbaise <goo...@soebes.de> wrote: > >> enforcement, other stuff). So for example, running a clean install and >> skipping all tests on a typical project versus clean install yields >> about 10-20% reduction in wall clock execution time. > > Skipping Test will of course reduce the time (Do you know how long the tests > alone take?) > but I wanted to know the exact "wasted" time you have mentioned by > compile/resources? > So running a linear (single thread) mvn clean install vs. mvn install (in > both cases with skipping tests at all)... > > If you always do a clean than Maven (plugins) can't identify things which > have already been done cause they are not there...so yes in this case you > are wasting time...
Maybe I am wrong, but I think the unit tests account for 10-20% of the time of the build in my example. When I run the exact same build with tests and then without tests, without tests is faster by 10-20% of the total time. Therefore I blame 10-20% of the time on tests and 80-90% of the time for the remainder of the build that will be in common for just about every run of the same project. Running clean every time only accounts for a small amount of the waste. I quickly did a test just now, on the same project I ran clean install and then install by itself, there was only a savings of 3% total time for omitting the clean phase. By 80-90% waste, I also meant that before discrete separate jobs/pipeline stages I could just stack all my goals into a single Maven invocation. The build would be very long, but I wouldn't pay the Maven POM initialization and other costs for general running multiple times. Finally, since our pipeline / CD strategy uses a per-build version with updated pom.xml for each release candidate branch, won't the updated pom.xml timestamp force a rebuild of all objects anyway? I think it ought to, even if Abc.java and Abc.class appear to be up to date and in sync, there's a more new pom.xml timestamp which should invalidate all previously built classes; assuming we are even lucky enough to run on the same node as previous stage, which seems increasingly unlikely given how many more steps we'll be running now, occupying more and more executors. -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAArU9iY1zcJHjZ4fFgHiTZ902Od2z%2B84kLUFa9N0JhjWLf1Ccg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
