Hi Andreas, in the company we usually just run mvn verify in branches/merge-requests and mvn deploy for default branch builds. To speed up things we create and publish docker images for smoke tests in another job parallel to the verify/deploy job which skips all tests, validation, verification etc. Of course these images might not be identical to the ones in verify/deploy but are similar enough. In my experience compiling is not the most time-consuming part of the build. Speeding up especially integration tests is what has the biggest impact, beter think about clustering correspondent tests to e.g. avoid spawning DBs via testcontainers too often.
Best regards Mirko On 2025/07/01 14:15:20 Andreas A Loew -Extern wrote: > Hi Tamás, hi Tim, hi All, > > Tamás Cservenák wrote: > > Thats the general idea in fact: > > 1st job: mvn install > > then "carry over local repo" > > 2nd and other jobs: work a top of prepopulated and installed from 1st > > job artifacts, running IT-like tests against them. > > Timothy Stone wrote: > > Take a look at the To Be Continuous Maven Pipeline templates. > > https://gitlab.com/to-be-continuous/maven > > Many thanks for your kind replies and ideas/feedback which have indeed been > very helpful for my understanding of the inner workings of the GitLab Runner > stages and jobs. > > The crucial idea that I borrowed from Tim's project and plan to base my > implementation on is that you can > > - define the whole workspace (including the sources) as a cache, and > - at the same time, stop GitLab from checking out everything again and thus > updating timestamps by setting GIT_STRATEGY to "none" > > So I now plan to set the whole workspace to be cached, do the Git checkout > (only) in the very first (build) stage, e.g. executing Maven verify/compile, > and set GIT_STRATEGY to "none" for all later stages/jobs, effectively > suppressing subsequent Git access, so Maven should detect that the sources > and generated sources (as re-copied into the working space from the cache at > the beginning of a new job they should - if I got the description of cache > behavior right - keep the timestamps the same) are unchanged and thus not > recompile etc. everything as part of every job... > > I will update you once I am finished implementing this approach - and I hope > to be able to report a success! 😉 > > Again, thanks to everybody for your kind help! 😊 > > Best regards > Andreas > > > ________________________________ > > Pflichtangaben anzeigen<https://www.deutschebahn.com/pflichtangaben/20250701> > > Nähere Informationen zur Datenverarbeitung im DB-Konzern finden Sie hier: > https://www.deutschebahn.com/de/konzern/datenschutz > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
