Lab 1 Report
De tag Lab1 die het resultaat markeert: https://gitlab.stud.atlantis.ugent.be/kaminnae/devops-project/-/tags/Lab1
successful run of the CI/CD job: d53459f0
Report on the structure of your .gitlab-ci.yml:
- Stages:
- build: compileert de java code met Maven
- package: bouwt het container image en pusht dit naar de GitLab Container Registry
- execute: voert de game uit
- Jobs:
- maven-build: compileert met ./mvnw (Maven wrapper)
- maven-container-image-generation: genereert het container image van de Quarkus service met de juiste environment variables
- run-game: start een game runner container als job service, die connecteert met de logic-service container
- Problemen en oplossingen: Ik had eens foute indentatie in mijn .gitlab-ci.yml bestand. Ik loste dit op door op GitLab naar Build → Pipelines te gaan en de pipeline te openen; daar kon ik direct zien welke fout de error veroorzaakte. Verder verliep het labo vlot.
Een ander aandachtspunt was het correct benoemen van commits. Ik gebruikte vaak copy-paste bij het pushen naar git en lette ik niet op de commit messages. Achteraf zag ik in de commitgeschiedenis dat dit geen goed idee was. Vanaf nu zal ik er bewust op letten om commits volgens de conventie correct te benoemen.
questions
What is ./mvnw and what is the advantage of using it above mvn?
./mvnw is de Maven Wrapper. het zorgt ervoor dat iedereen dezelfde Maven-versie gebruikt, ook als Maven niet lokaal geïnstalleerd is. Het voorkomt problemen door verschillen in Maven-versies tussen machines.
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?
Cache wordt gedeeld tussen jobs en pipelines. Ideaal voor bestanden die hergebruikt kunnen worden, zoals Maven dependencies (.m2/repository). Ik heb dit gebruikt voor dependencies om ze niet elke keer opnieuw te downloaden.
Artifacts worden opgeslagen per pipeline en zijn beschikbaar voor latere jobs in dezelfde pipeline. Ik heb dit gebruikt voor target/ build files zodat latere jobs (bv. container build of run-game) deze kunnen gebruiken zonder opnieuw te compileren.
Trade-offs: Cache kan in meerdere pipelines gebruikt worden, maar is niet per job gegarandeerd; artifacts zijn altijd beschikbaar voor volgende jobs in dezelfde pipeline, maar nemen opslag op de GitLab server in beslag en vervallen na een bepaalde tijd.
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?
we gebruiken een 25-jre image voor de runtime, omdat deze kleiner is en enkel nodig is om de java-applicatie uit te voeren. Voor de CI/CD build jobs gebruiken we een 25-jdk image, omdat deze naast de runtime ook de compiler en andere tools bevat die nodig zijn om het project te bouwen en Maven-tasks uit te voeren. Als we 25-jdk voor beide zouden gebruiken, zou zowel de build als de runtime werken, maar het runtime image zou groter zijn dan nodig. Als we 25-jre voor beide zouden gebruiken, zou dat betekenen dat de runtime werkt, maar de CI/CD builds zouden falen omdat de compiler en andere benodigde buildtools ontbreken