Skip to content

Lab 1 Report

Succesvolle Pipeline Run

Link: Pipeline #77736

Pipeline Structuur Rapport

.gitlab-ci.yml Structuur

De pipeline bestaat uit 3 stages:

  • build: Compileert de Java-code met Maven
  • package: Bouwt en pushed de Docker-image naar GitLab's container registry
  • execute: Voert een game-simulatie uit met de gebouwde Docker-image

Problemen en Oplossingen

Probleem 1: Fout CI/CD pipeline initialiseren, inloggen faalt

  • Oorzaak: Had het project nog niet op mijn profiel gezet, was rechtstreeks op de admin aan het werken
  • Oplossing: Project verplaats naar mijn profiel Probleem 2: Initiële 401 Unauthorized-fouten bij het pushen naar container registry
  • Oorzaak: Gebruikte $CI_PROJECT_NAMESPACE in plaats van $CI_PROJECT_PATH voor het image registry-pad
  • Oplossing: Veranderd naar $CI_PROJECT_PATH wat het volledige project-pad correct formatteert

Probleem 3: Maven-afhankelijkheden niet gedeeld tussen jobs

  • Oplossing: Voegde globale cache toe voor .m2/repository/ en stelde dependencies: velden in voor correcte artifact-doorvoer

Antwoorden vragen

1. What is ./mvnw and what is the advantage of using it above mvn? Het commando ./mvnw (Maven Wrapper) is een script dat automatisch een specifieke versie van Maven downloadt en gebruikt die voor het project is geconfigureerd, in plaats van te vertrouwen op een globaal geïnstalleerde Maven-versie.

Het grootste voordeel van ./mvnw ten opzichte van mvn is dat het zorgt voor versieconsistentie tussen ontwikkelaars en CI/CD-pipelines, waardoor problemen door verschillende Maven-versies worden voorkomen. Daarnaast hoeven nieuwe ontwikkelaars Maven niet handmatig te installeren, omdat het wrapper-script dit automatisch regelt. De gebruikte Maven-versie wordt bovendien in de projectmap opgeslagen, waardoor ze geïsoleerd blijft van andere projecten of systeeminstallaties. Dit draagt bij aan een hogere reproduceerbaarheid, omdat dezelfde Maven-versie op elk systeem kan worden gebruikt. Tot slot maakt het gebruik van ./mvnw de CI/CD-configuratie eenvoudiger, omdat systemen zoals GitLab-runners Maven niet vooraf hoeven te hebben geïnstalleerd.

2. Explain the key differences between GitLab's cache and artifacts mechanisms. For each of Maven dependencies and build files, explain which mechanism you chose and why. What are the trade-offs of your choices?

De cache in GitLab is bedoeld voor tijdelijke build-outputs die opnieuw kunnen worden gegenereerd. Deze cache kan worden gedeeld tussen verschillende jobs en pipelines, maar kan ook door GitLab worden verwijderd wanneer opslagruimte nodig is. De cache is vooral geschikt voor Maven-afhankelijkheden, zoals de inhoud van de map .m2/repository, of voor gedownloade bibliotheken. Het voordeel is dat deze snel opnieuw beschikbaar zijn, maar het nadeel is dat de cache niet gegarandeerd aanwezig blijft. Artifacts daarentegen zijn bedoeld voor de eindproducten van builds die moeten worden bewaard. Ze worden enkel opgeslagen voor de huidige pipeline en blijven bewaard gedurende een configureerbare periode, zoals één uur of één dag. Volgende jobs kunnen deze artifacts downloaden wanneer ze expliciet als dependencies zijn aangeduid. Ze zijn geschikt voor gecompileerde code (zoals de inhoud van de target/-map), Docker-images of testrapporten. Het voordeel van artifacts is dat ze gegarandeerd bewaard blijven, maar ze gebruiken wel meer opslagruimte. In dit labo werden de Maven-afhankelijkheden opgeslagen via de cache, omdat deze bestanden groot zijn, opnieuw kunnen worden gedownload en tussen pipelines behouden moeten blijven. Dit voorkomt dat dezelfde afhankelijkheden telkens opnieuw van het internet moeten worden gedownload. De build-bestanden, zoals de inhoud van de target/-map, werden echter opgeslagen als artifacts, omdat dit de gecompileerde output is die nodig is voor de volgende fasen, zoals het packagen en uitvoeren van de applicatie. Deze bestanden moeten beschikbaar blijven voor de container-image-generatie en de uitvoering van de game, en artifacts garanderen deze persistentie binnen de pipeline. De belangrijkste trade-offs zijn dat caching minder opslagruimte vereist maar minder betrouwbaar is, terwijl artifacts betrouwbaarder zijn maar meer opslagruimte gebruiken. Het delen van cache tussen pipelines is efficiënt, maar kan leiden tot conflicten met nieuwere code. Artifacts met expliciete dependencies zorgen daarentegen voor een duidelijke en gecontroleerde datadoorvoer tussen jobs.

3. In this lab, we use a 25-jre image as the base for our runtime container and a 25-jdk image for the CI/CD build jobs. Explain the reasoning behind this choice. What would be the impact (positive or negative) of using 25-jdk for both? What about using 25-jre for both?

De JRE (Java Runtime Environment) bevat enkel de Java Virtual Machine (JVM) en de noodzakelijke runtime-bibliotheken om gecompileerde Java-code uit te voeren. Het is een minimale omgeving die kleiner is in omvang (ongeveer 200 tot 300 MB) en veiliger is doordat ze minder tools bevat en dus een kleiner aanvalsoppervlak heeft. De JDK (Java Development Kit) bevat alles wat in de JRE zit, maar voegt daar de Java-compiler, debugging-tools en ontwikkelingsbibliotheken aan toe. Deze image is groter (ongeveer 500 MB of meer) en is enkel nodig tijdens de build-fase om Java-broncode te kunnen compileren. In dit labo werd gekozen voor de combinatie van 25-jdk voor de CI/CD build-jobs en 25-jre voor de runtime-containers. Deze keuze volgt het principe van het gebruik van minimale, passende tools voor elke fase van het proces. De build-jobs vereisen de JDK omdat de broncode moet worden gecompileerd met de javac-compiler, terwijl de runtime-containers enkel de JRE nodig hebben omdat de code al gecompileerd is in JAR-bestanden. Het gebruik van 25-jdk voor zowel de build- als de runtime-fase zou als voordeel hebben dat de configuratie eenvoudiger wordt en er slechts één image onderhouden hoeft te worden. Het nadeel is echter dat de runtime-containers onnodig groot zouden worden (meer dan 300 MB groter), onnodige ontwikkeltools zouden bevatten en daardoor een groter aanvalsoppervlak en tragere starttijd zouden hebben. Bovendien zou dit meer systeembronnen verbruiken in productie en het principe van “least privilege” schenden. Het gebruik van 25-jre voor zowel build als runtime zou daarentegen leiden tot een consistente, kleinere image-grootte, maar de builds zouden mislukken omdat de Java-compiler (javac) niet aanwezig is in de JRE. Daardoor kan de broncode niet worden gecompileerd. De conclusie is dat de huidige keuze — JDK voor de build-fase en JRE voor de runtime-fase — de optimale balans biedt. Deze aanpak voorziet in de nodige tools tijdens de build terwijl de runtime-containers klein, efficiënt en veilig blijven.