Sorry for the confusion, but I was referring to ‘job artifacts’ in the context of GitLab (https://docs.gitlab.com/ci/jobs/job_artifacts/), not Maven artifacts.
Nils. > Op 26 jun 2025, om 16:09 heeft Tamás Cservenák <ta...@cservenak.net> het > volgende geschreven: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
