Lab 1 Report

Link to succesful run of the CI/CD pipeline

Link: https://gitlab.stud.atlantis.ugent.be/micvhoor/devops-project/-/pipelines/78035

Structure of .gitlab-ci.yml

1. Set up the global variables of the yaml file.
2. Set up a cache with key: "maven-cache", this cache works across branches
3. Define the three stages of the pipeline.
4. The build stage:
   1. Compile the source code with mvn.
   2. make an artifact to pass to future stages.
5. The image generation stage:
   1. Print all the environment variables. Useful for debugging.
   2. Build a docker image for the logic service and store it in the Gitlab container registry.
6. The execution stage:
   1. Start a docker container generated from the image created in the previous stage.
   2. Set up some local variables.
   3. Launch the game.

Problems

1. To make another player join the game on a linux machine I had to add the following code in rc/main/resources/application.properties: "quarkus.http.host=0.0.0.0", this makes sure all hosts get bound and not only localhost.

2. I had trouble generating the Docker image with my GitLab CI pipeline. I kept getting errors saying i was unauthorized. Because of these typos, the pipeline wasn’t using the correct login information for the container registry. Fixing these variables solved the problem.

Questions

1. What is ./mvnw and what is the advantage of using it above mvn? ./mvnw is a Maven wrapper script that comes with the project. This wrapper downloads a project-compatible version of Maven that will only be used within the context of this project. Using Maven wrapper makes it easier for developers to collaborate and prevents you from having to install Maven on your system.

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?

   • A cache is one or more files a job downloads and saves. Subsequent jobs that use these same files don't have to download them again but can get them from the cache.
   • Jobs can output an archive of files and directories. This output is known as a job artifact.
   • The key difference between caches and artifacts is the fact that caches are used to store dependencies and artifacts are used to pass intermediate build results between stages. An artifact is generated by a job and a cache is used to store things like packages downloaded from the internet.
   • I chose to use a cache for the for the build stage because Maven has a lot of cache files and dependencies, so there is a lot of merit to use a cache to speed up the build phase. It is also unnecessary to make an artifact of the docker image, because this is already stored in my Gitlab container registry. The trade off of using a cache is that it uses storage.

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?

   • You use 25-jdk for CI/CD build build jobs because the JDK contains the Java compiler and build tools you need to compile and package the app. You use 25-jre for runtime because it contains only the runtime environment needed to run compiled java applications, these images are significantly smaller and more secure as they exclude unnecessary development tools.
   • If you would use 25-jdk for both, everything would work, but you would have too much unnecessary data because a runtime environment does not need a compiler for example. This would make your image way larger and less secure than it needs to be.
   • If you would use 25-jre for both, you would be unable to complete the CI/CD build jobs and thus not be able to successfully run the pipeline