Skip to content

Lab 1 Report

Pipeline

CI/CD structuur

  • Stages: build (compile met Maven wrapper), package (Jib bouwt en pusht de image), execute (devops-runner simuleert 100 beurten met mijn image).

  • Cache houdt .m2/repository bij tussen jobs; maven-build publiceert target/ als artifact voor de volgende stage.

  • run-game draait op het devops-runner-image en start mijn service als job-service (CI_REGISTRY_IMAGE/logic-service:latest).

Antwoorden op vragen

  1. Waarom ./mvnw? Dit is een Maven wrapper die ervoor zorgt dat de juiste Maven-versie per project gebruikt wordt, waardoor iedereen dezelfde toolchain heeft zonder problemen.

  2. (i) Gitlab Cache vs artifacts

    Cache

    • Gedeelde opslag tussen jobs en pipelines
    • Werkt via cache key matching
    • Ideaal voor dependencies die weinig veranderen
    • Kan verouderen of corrupt raken, geen automatische opschoning

    Artifacts

    • Job-outputs binnen de pipeline
    • Beperkte levensduur (expire_in)
    • Altijd up-to-date en betrouwbaar
    • Kost storage, niet herbruikbaar buiten pipeline

    (ii) Leg voor elk van de Maven-dependencies en build-bestanden uit welk mechanisme je hebt gekozen en waarom

    Maven dependencies (.m2/repository) → Cache

    • Key: $CI_PROJECT_NAME
    • Policy: pull-push
    • Reden: downloaden kost tijd, wijzigt zelden
    • Risico: bij corruptie cache wissen of key aanpassen

    Build files (target/) → Artifacts

    • Expire: 7 dagen
    • Gebruik: alleen binnen pipeline (voor Jib-job)
    • Reden: downstream job krijgt exacte build-versie
    • Nadeel: niet herbruikbaar in volgende pipelines

  3. (i) Waarom in de pipeline een 25-jdk image en de runtime-container op 25-jre?

    • Build-jobs moeten compileren (javac), testen draaien, Jib uitvoeren enz. Die tooling zit enkel in een JDK; in een JRE ontbreekt de java compiler en andere hulpprogramma’s, dus de job zou falen bij ./mvnw compile.
    • Zodra de service gebouwd is, heeft ze alleen de JVM-runtime nodig.
    • Een JRE-image is kleiner, start sneller en verbruikt minder.
    • Het sluit aan bij best practice: CI bouwt met een JDK, productie draait op een minimale runtime.

    (ii) Wat als we overal 25-jdk gebruiken?

    • Dat zou ook werken, maar de runtime-image wordt onnodig groot en kan extra security-risico’s meebrengen. Je sleept tooling mee die in productie helemaal niet meer nodig is.

    (iii) Wat als we overal 25-jre gebruiken?

    • De build-jobs zouden al bij de compilatiestap crashen (geen javac/jar/debug-tools).
    • Zelfs als je lokaal compileert en alleen jars meeneemt, verlies je tests, codegeneratie en veel Maven-plugins die expliciet op de JDK rekenen.
    • Kortom: CI faalt en je pipeline “compileert” niet meer.

Issues & Fixes

  • run-game faalde eerst door een hoofdletter in de registry-pad; opgelost door overal CI_REGISTRY_IMAGE (lowercase) te gebruiken.
  • Op Linux extra_hosts geactiveerd zodat de runner host.docker.internal kan bereiken.