Skip to content

Lab 1 Report

Lab 1 Report

Labels: Report, Lab 1
Auteur: Sander De Clercq
Datum: 13/10/2025

Link naar succesvolle CI/CD run

https://gitlab.stud.atlantis.ugent.be/sandedcl/devops-project/-/jobs/247437

Structuur van .gitlab-ci.yml

De pipeline heeft de volgende stages:

  • build
    Job: maven-build — voert ./mvnw compile uit. Deze job:
    • cachet de Maven repository (.m2/repository) zodat dependencies bewaard blijven tussen pipelines,
    • produceert artifacts: target/ (gecompileerde output).
  • package
    Job: maven-container-image-generation — pakt de gecompileerde artefacten en bouwt/pusht een container image (via Quarkus container build). Deze job:
    • gebruikt dependencies: om de artifacts van maven-build te downloaden,
    • gebruikt dezelfde cache key voor .m2/repository zodat dependencies hergebruikt worden.
  • execute
    Job: run-game — start een run van de game tegen de eerder gepushte container image als service en voert de runner class uit.

Problemen die ik ben tegengekomen

  • Bij het automatiseren van de container image zorgde de debug-echo voor problemen, dit kon ik oplossen door deze in commentaar te zetten.
  • Het aanmaken van de pipe zorgde even voor problemen door een schrijffout in de bestandsnaam, dit was dan makkelijk opgelost eenmaal de fout gediagnoseerd was.
  • Er was een probleem bij het opstarten van de QUARCUS-service, dit kon opgelost worden met de oplossing uitgelegd in de opgave. Het grootste probleem was de service sluiten zodat ik een nieuwe service kon opstarten.

Antwoorden op de vragen

  • Wat is ./mvnw en wat is het voordeel t.o.v. mvn? ./mvnw is de Maven Wrapper: een shell script (en bijbehorende .jar) dat ervoor zorgt dat een specifiek versie van Maven automatisch gedownload en gebruikt wordt door het project, ongeacht welke Maven-versie op de CI-runner aanwezig is. Voordelen:

    • Consistente Maven-versie over alle ontwikkelmachines en CI-runners.
    • Geen vereiste dat mvn vooraf geïnstalleerd is op de runner image.
    • Eenvoudiger reproduceerbaarheid van builds.

  • Verschillen tussen GitLab cache en artifacts — en welke kies je voor wat?

    • Cache:
      • Doel: m bestanden tijdelijk te bewaren tussen jobs of pipelines om herhaald werk te vermijden (het herinstalleren van dependencies).
      • Levensduur: Wordt automatisch opgeruimd na een tijdje
      • Delen: Kan worden gedeeld tussen jobs binnen dezelfde pipeline of branch, afhankelijk van de cache-key.
    • Artifacts:
      • Doel: Om output van jobs (zoals build-resultaten, testlogs, binaries) op te slaan en door te geven aan volgende jobs
      • Levensduur: Kan je zelf instellen (bijv. expire_in: 1 week), maar bedoeld om langer te bewaren dan cache.
      • Delen: Alleen tussen jobs die via needs of dependencies met elkaar verbonden zijn.
    • Maven dependencies (.m2/repository)
      • Keuze: cache.
      • Waarom: dependencies zijn grote, herbruikbare caches tussen pipelines en builds; je wil ze persistent hergebruiken over meerdere pipelines. Cache is daarvoor gemaakt.
    • Build files (target/)
      • Keuze: artifacts.
      • Waarom: target/ is een specifieke geproduceerde build van een bepaalde pipeline run en moet precies zo doorgegeven worden naar de package job om te voorkomen dat je opnieuw compileert. Artifacts garanderen een consistente, immutable set files per pipeline.

  • Gebruik van 25-jre (runtime) vs 25-jdk (build jobs)

    • Waarom runtime = 25-jre en build = 25-jdk?
      • JDK bevat de compiler, tools en debug utilities die nodig zijn tijdens het bouwen/compileren van je applicatie. Je hebt de JDK nodig in de CI-stap waar je mvn package of andere compilatie/naar-native bouwstappen uitvoert.
      • JRE is compacter en bevat alleen wat nodig is om Java-apps uit te voeren. Voor het uitvoeren van de applicatie volstaat de JRE en dat scheelt in image grootte.
    • Wat gebeurt er als je 25-jdk voor beide gebruikt?
      • Positief:
        • Je hebt in de runtime altijd alle tools beschikbaar als je later toch iets wilt compileren/debuggen.
        • Eenvoudigere beheer (één base image).
      • Negatief:
        • Grotere container images
        • Meer attack surface (meer packages, tools), iets minder veilig.
        • Onnodige opslag-/bandbreedtekosten in productie.
    • Wat gebeurt er als je 25-jre voor beide gebruikt?
      • Positief:
        • Kleinere images en snellere pulls.
        • Minder attack surface.
      • Negatief:
        • Build jobs falen omdat javac en andere build tools ontbreken. Je kan niet compileren zonder JDK.
        • Eventuele build-time tools van Quarkus of plugins werken niet.
Edited by Sander De Clercq