The problem is that "That way you wouldn’t need to pass any artifacts between multiple jobs." is untrue, here they do not pass (built/installed) "artifacts" but checkout _files_ ?
T On Thu, Jun 26, 2025 at 3:59 PM Nils Breunese <n...@breun.nl> wrote: > > Would it be an option to just do everything (build, test, code quality, etc.) > in a single Maven execution in a single GitLab job? That way you wouldn’t > need to pass any artifacts between multiple jobs. > > Nils. > > > Op 26 jun 2025, om 15:06 heeft Andreas A Loew -Extern > > <andreas.a.loew-ext...@deutschebahn.com> het volgende geschreven: > > > > Hello Maven experts, > > > > having started to make a big legacy enterprise Java project (which > > previously used Jenkins) ready to build through GitLab CI/CD, I ran into > > the exact same problems as described here with regards to an obvious misfit > > between the concepts of GitLab Runner CI/CD and Maven: > > > > https://gitlab.com/gitlab-org/gitlab/-/issues/234078 > > > > __________ > > > > The issue here is related to how both Maven and Git work. Here's a little > > bit of context: > > > > · Git doesn't store timestamps, this means that every file > > resulting from a git clone operation will have the current timestamp > > · Maven checks files in the target/source-classes directory and > > compares them with files in src to understand if they need to be compiled > > again, and it uses the timestamp to determine if the source code is newer > > than the built one > > · GitLab CI jobs do a git clone to retrieve the repository, meaning > > that all the files in the working dir have the current timestamp > > · GitLab CI jobs store folder artifacts as a zip file and those > > files are unzipped in following jobs, causing the artifacts to have as > > timestamp the moment where they were created in the previous job > > > > If considering the Maven scenario, this means that files in > > target/source-classes will look older than the files in src, triggering a > > full build instead of using the already built classes. > > > > Why does this matter? Let's say we have a pipeline where the first step is > > to build our project and then we have multiple steps that execute other > > goals like unit tests, code quality and so on, with the current behavior > > Maven will fully rebuild the project in every job of our pipeline. > > > > From our point of view, this is a big issue because it prevents us to share > > build artifacts between jobs. > > _________ > > > > Also, the fact that during the run of one pipeline, every single stage does > > a fresh Git checkout and a fresh Maven generate-sources and compile > > (including tests), is clearly completely suboptimal in terms of “Green IT” > > and a true waste of compute and I/O resources as well as time… ☹ > > > > Is there any established strategy in the Maven community on how to set up > > continuous builds/deployments using GitLab CI/CD? Or are we still – 5 years > > after the above issue has been opened with GitLab – lacking a “standard” > > solution here? > > > > Many thanks in advance for your kind help & best regards > > Andreas > > -- > > Andreas Loew > > > > externe Fachkraft im Auftrag der > > Wavestone Germany AG > > Leopoldstraße 28a, D-80802 München > > > > im Auftrag der > > DB Energie GmbH (I.EFN 2) > > Im Galluspark 25, D-60326 Frankfurt am Main > > E-Mail: > > andreas.a.loew-ext...@deutschebahn.com<mailto:andreas.a.loew-ext...@deutschebahn.com> > > > > > > ________________________________ > > > > Pflichtangaben > > anzeigen<https://www.deutschebahn.com/pflichtangaben/20250625> > > > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
