Skip to content

Lab 1 Report

Successful run

https://gitlab.stud.atlantis.ugent.be/naheyrma/devops-project/-/pipelines/78002/

.gitlab-ci.yml structure

The .gitlab-ci.yml file behind the above mentioned job defines a three stage pipeline with the stages build, package and execute. in the first stage(maven-build) the Maven project is compiled using ./mvnw compile and the build files are made into an artifact to be used later.

In the package stage(maven-container-image-generation) the application is packaged into a Quarkus container image using environment variables to set the Quarkus configuration values. This container image is then pushed to the GitLab integrated Container Repository. An issue I ran into during this stage was finding the correct CI/CD variables to use for the packaging stage and the cache key, for this I used the GitLab docs sites https://docs.gitlab.com/ci/variables/predefined_variables/ and https://docs.gitlab.com/ci/caching/ to find out which variables I needed to use.

The last stage(run-game) automates running the game by using the devops-runner to run the game logic. In this stage the devops-runner is also configured with a set amount of turns, a player name, a turn interval and the URL at which the faction logic service can be reached.

Answers to the questions

  • What is ./mvnw and what is the advantage of using it above mvn?
    • ./mvnw refers to a Maven wrapper script that comes with the project which downloads a project-compatible version of Maven. The advantage of this is that everyone running the project uses the same Maven version and there is no need for everyone to install Maven.
  • 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?
    • A GitLab cache reuses files between different pipelines and jobs to speed up builds and stores these files on the computer that runs the project. An artifact on the other hand passes files between different stages in the same pipeline and can be downloaded from the pipeline view, these artifacts are also stored on the GitLab server.
    • To make sure the Maven dependencies were available in subsequent jobs I used caching because they needed to be stored between individual runs. This means the dependencies won't be downloaded every time, reducing build time.
    • To make sure the build files are available in subsequent jobs i stored the build files in the target/ directory as artifacts which allows them to be easily used in the run-game stage. Storing these build files as artifacts was the best choice since these files are specific to one pipeline run, a side effect of using artifacts though is that up/downloading them adds time to a job.
  • 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 the 25-jre image as the base because our application is already compiled and JRE images contain only the Java Runtime Environment needed to run compiled java applications. we use the 25-jdk image for the CI/CD build jobs because JDK images contain the full Java Development Kit, which is necessary for building java applications.
    • If we were to use 25-jdk for both the project would still work but the image for the runtime container would be much larger making it much slower and more resource heavy since it would contain unnecessary compiler tools.
    • If we were to use 25-jre for both the build would fail since the JRE would miss the compiler necessary for the CI/CD build jobs.