Lab 1 Report

Report Lab 1

Link

Link naar een succesvolle uitvoering van de CI/CD-taak die het spel heeft uitgevoerd

Rapport over de structuur van `.gitlab-ci.yml`

Pipeline Structuur

De pipeline is gestructureerd in drie sequentiële stages, elk met één job:

build: De job maven-build compileert de code. De job is geoptimaliseerd door Caching van Maven dependencies (.m2/repository) en het doorsturen van de build output (target/) als Artifacts naar de volgende job.
package: De job maven-container-image-generation bouwt de Docker container image met Jib en pusht deze naar de GitLab Container Registry. Deze job is afhankelijk van de artifacts van de build stage.
execute: De job run-game voert de geautomatiseerde game-sessie uit. Het gebruikt de devops-runner image als hoofdcontainer en start de zojuist gepushte logic-service image als een Job Service voor de integratietest.

Problemen en Oplossingen

Tijdens de ontwikkeling kwam ik 2 problemen tegen die directe fixes in de YAML-configuratie vereisten:

1. YAML Syntaxfouten (`yaml invalid`)

Probleem: De pipeline faalde meermaals door inconsistente inspringing en een foutieve escape-sequentie (\$) in de MAVEN_OPTS variabele. De YAML-parser interpreteerde deze foutief.
Oplossing: Dit is opgelost door alle commentaar te verwijderen en de variabele MAVEN_OPTS aan te passen om enkele aanhalingstekens (') te gebruiken. Dit zorgde ervoor dat de backslash niet nodig was en de variabele correct werd geparseerd:
```
MAVEN_OPTS: '-Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository'
```

2. Job Service Image Path

Probleem: De run-game job faalde omdat het pad naar de logic-service image in de Container Registry verkeerd was opgebouwd, wat leidde tot de fout invalid service image name.
Oplossing: Het imagepad voor de Job Service werd gewijzigd naar de ingebouwde variabele $CI_REGISTRY_IMAGE.
```
services:
  - name: $CI_REGISTRY_IMAGE/logic-service:latest
    alias: logic-service
```

Vragen

1. Wat is `./mvnw` en het voordeel tegenover `mvn`?

./mvnw is een Maven Wrapper script. Het is een project-specifiek script dat automatisch de juiste, compatibele versie van Maven zal gebruiken die is gedefinieerd voor dat project.

Het grootste voordeel van de wrapper is dat je niet eerst Maven hoeft te installeren en dat iedereen binnen het team dezelfde versie gebruikt. Zo voorkom je problemen waarbij een project bij de ene ontwikkelaar wel bouwt, maar bij de andere niet, omdat ze een andere Maven-versie hebben.

2. Leg de belangrijkste verschillen uit tussen de cache- en artefactmechanismen van GitLab. Leg voor elke Maven-afhankelijkheid en elk buildbestand uit welk mechanisme je hebt gekozen en waarom. Wat zijn de voor- en nadelen van je keuzes?

GitLab CI/CD biedt twee mechanismen om bestanden tussen jobs te behouden: Cache en Artifacts.

Cache gebruik je om externe afhankelijkheden te hergebruiken, zoals gedownloade Maven-bibliotheken. De cache wordt gedeeld tussen verschillende pipelines en jobs, en is ideaal voor bestanden die niet vaak veranderen, zo hoef je die niet telkens opnieuw te downloaden, wat veel tijd scheelt.
Artifacts gebruik je om de output van een job door te geven aan de volgende job. Denk bijvoorbeeld aan de gecompileerde bestanden of het buildresultaat van Maven. Artifacts worden opgeslagen op de GitLab-server en zijn alleen beschikbaar binnen dezelfde pipeline.

Keuze en voor- en nadelen

Maven Dependencies (.m2/repository): Cache
- Waarom: Deze bestanden veranderen zelden en het is handig als ze beschikbaar blijven tussen verschillende pipeline-runs. Zo hoef je de afhankelijkheden niet telkens opnieuw te downloaden, wat de build aanzienlijk versnelt.
- Voor- en nadelen: De cache kan soms verouderde bestanden bevatten, maar dat nadeel weegt meestal niet op tegen de winst in snelheid.
Build Files (target/ folder): Artifacts
- Waarom: Dit zijn de outputbestanden van de build-job die nodig zijn voor de volgende stap in de pipeline, bijvoorbeeld de package-job. Met artifacts weet je zeker dat de juiste bestanden worden doorgegeven binnen dezelfde pipeline.
- Voor- en nadelen: Artifacts nemen extra opslagruimte in op de GitLab-server en kunnen niet direct worden hergebruikt in andere pipelines, maar ze zorgen wel voor betrouwbaarheid binnen één run.

3. In dit lab gebruiken we een 25-jre-image als basis voor onze runtime-container en een 25-jdk-image voor de CI/CD-buildtaken. Leg uit waarom we hiervoor hebben gekozen. Wat zou het effect (positief of negatief) zijn als we voor beide 25-jdk zouden gebruiken? En als we voor beide 25-jre zouden gebruiken?

De keuze om 25-jdk te gebruiken voor de build en 25-jre voor de runtime volgt de best practice om productiecontainers zo klein, efficiënt en veilig mogelijk te houden.

Waarom

De Java Development Kit (JDK) is nodig tijdens de buildfase omdat deze de compiler (javac) bevat, zonder die kun je de Java-broncode niet omzetten naar uitvoerbare bytecode.
De Java Runtime Environment (JRE) is voldoende voor de runtimefase, omdat deze alleen de JVM en de standaardbibliotheken bevat die nodig zijn om de reeds gecompileerde applicatie te draaien. Hierdoor wordt de uiteindelijke container lichter, sneller te deployen en minder kwetsbaar voor beveiligingsproblemen.

Wat als je iets anders zouden kiezen?

25-jdk gebruiken voor zowel build als runtime: Dit zou prima werken, maar de runtimecontainer wordt dan onnodig groot en bevat tools die je in productie niet nodig hebt. Dat vergroot niet alleen de imagegrootte, maar ook het aanvalsoppervlak, dus minder veilig en minder efficiënt.
25-jre gebruiken voor zowel build als runtime: De runtime zelf zou blijven werken, maar de build zou mislukken, omdat de JRE geen compiler (javac) bevat. Zonder JDK kun je de broncode simpelweg niet compileren.

Edited Nov 03, 2025 by Jasper Vaneessen