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
