Skip to content

Lab 1 Report

Lab 1 Report – CI/CD Pipeline

1. Link naar succesvolle run

De CI/CD job die het spel heeft uitgevoerd is succesvol en kan hier bekeken worden:
CI/CD job run

2. Report on the structure of .gitlab-ci.yml

Voor dit lab heb ik een pipeline opgezet met drie stages: build, package en execute. Elke stage heeft één job:

  • maven-build compileert de Java code met ./mvnw compile.
  • maven-container-image-generation bouwt en pusht de Docker image van de logic-service naar de GitLab Container Registry.
  • run-game start de game host zodat het spel correct kan draaien en de CI/CD Player kan meespelen.

De logic-service wordt gestart als Job Service binnen de run-game job. Hierdoor kan de runner communiceren via http://logic-service:8080 en wordt de integratie tussen de game en de logic-service getest.

Om te zorgen dat Maven dependencies en build output beschikbaar blijven tussen jobs, heb ik gebruikgemaakt van caches en artifacts. Dit maakt de pipeline sneller en voorkomt dat resources onnodig worden verspild.

Het lab verliep vlot en er zijn geen echte problemen opgetreden. Alles werkte zoals verwacht en de pipeline voerde de taken correct uit.

3. Questions

What is ./mvnw and what is the advantage of using it above mvn?
./mvnw is de Maven Wrapper. Het script downloadt automatisch de juiste Maven-versie en gebruikt die, ook als Maven lokaal niet geïnstalleerd is. Het voordeel is dat builds consistent en reproduceerbaar zijn, zowel op je eigen machine als in de CI/CD omgeving, zonder dat je je zorgen hoeft te maken over de lokale Maven-versie.

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?

In GitLab CI/CD gebruiken we cache en artifacts om bestanden tussen jobs beschikbaar te maken, maar ze werken op verschillende manieren. Cache wordt gedeeld tussen jobs én pipelines en is handig voor bestanden die vaak terugkomen, zoals Maven dependencies. Deze bestanden hoeven niet elke keer opnieuw te worden gedownload, waardoor de pipeline sneller draait. Het nadeel is dat de cache soms verouderd kan zijn en je deze moet bijwerken als dependencies veranderen.

Artifacts zijn daarentegen alleen beschikbaar binnen dezelfde pipeline en worden gebruikt voor bestanden die specifiek nodig zijn voor de volgende job, zoals build output in de target/ folder. Ze worden opgeslagen op de GitLab-server en kunnen later gedownload worden, maar ze nemen wel serverruimte in beslag en zijn niet automatisch beschikbaar in andere pipelines.

In deze pipeline heb ik ervoor gekozen om Maven dependencies in cache op te slaan en de build output als artifacts. Dit betekent dat dependencies hergebruikt kunnen worden in toekomstige pipelines, terwijl de gecompileerde bestanden direct beschikbaar zijn voor de volgende job, bijvoorbeeld om de Docker image te bouwen. Op deze manier blijft de pipeline snel en efficiënt, zonder dat resources onnodig worden verspild.

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 build jobs hebben een JDK nodig om te kunnen compileren, terwijl de runtime container alleen een JRE nodig heeft, waardoor het image kleiner en sneller te deployen is. Als beide stages een JDK zouden gebruiken, wordt het image onnodig groot en duurt het downloaden langer. Als beide stages een JRE zouden gebruiken, kan de code niet gecompileerd worden en mislukt de pipeline.