Lab 1 Report

Lab 1 Report

Link to a successful run of the CI/CD job that executed the game

Link: https://gitlab.stud.atlantis.ugent.be/jewijnan/devops-project/-/jobs/248324

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

Structure of my .gitlab-ci.yml

The .gitlab-ci.yml is organized into three main stages: build, package and execute.

Build

The build stage contains the maven-build job, which is responsible for compiling the project. In order to reuse the compiled files in later stages without rebuilding, the target/ folder is saved as artifacts. This allows downstream jobs, such as container image generation, to access the compiled code directly, avoiding unnecessary recompilation.

Package

The package stage contains the maven-container-image-generation job. Its role is to automatically build a container image of the Faction Logic service and push it to the GitLab Container Registry. This job relies on environment variables to configure the Quarkus container image, including credentials, registry location, image group, and tag. By using the artifacts from the build stage, the container job can reuse compiled classes, speeding up the pipeline.

Execute

The execute stage contains the run-game job. This job runs an automated game session to verify that the logic service is functional. To do this, the job uses the container image created in the previous stage as a Job Service, ensuring it is reachable at a specific URL. Environment variables control the player name, the URL of the logic service, the turn interval, and the turn limit, allowing the game to run automatically without blocking the pipeline.

Problems I have encountered and how I have solved them

I didn't encounter many problems during the development of this pipeline. The only problem I have encountered was a YAML parsing error, caused by improper spacing in the cache and variable definitions. This was fixed by ensuring there was a space after colons and quoting all values that contained colons, such as Maven options.

Answers on the questions

1. What is ./mvnw and what is the advantage of using it above mvn?
   • ./mvnw is the Maven Wrapper, a script included in the project that ensures the project always uses a specific Maven version. Unlike mvn, it doesn’t require Maven to be installed on the system, which guarantees consistent builds across different machines and CI/CD pipelines. This makes builds reproducible and simplifies setup, as all jobs and developers use the same Maven version automatically.
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?
   • GitLab cache is used for long-lived files shared across jobs and pipelines, while artifacts are for files specific to a single pipeline. In this lab, Maven dependencies were cached to avoid repeated downloads across pipelines, and build outputs (target/ folder) were stored as artifacts to pass them to downstream jobs within the same pipeline. The trade-off is that caches may be evicted or missed, while artifacts do not speed up future pipelines but ensure correctness within the current one.
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?
   • We use 25-jdk for CI/CD build jobs because it includes the compiler needed to build the project, and 25-jre for the runtime container because it only needs to run the application. Using JDK for both would make the container larger and include unnecessary tools, while using JRE for both would break the build since the compiler would be missing.