Lab 1 Report

What is ./mvnw and what is the advantage of using it above mvn?

the difference between mvn and mvnw is mvnw is maven wrapper. This runs mvn underneath but also ensures that all maven packages and dependencies are installed if they wouldn't have been installed yet. This makes setup easier and faster.

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 is intended for usage for dependencies such as with node for /node-modules or any maven dependencies. Artifacts are more for later stages where they are stored and then passed onto these later stages, like when you execute the run-game stage twice, it can use the artifact from earlier instead of having to rebuild it.

I mostly made use of the cache, to store all the maven dependencies without having to download them again all the time. After the first run this is very fast, the trade-off is that the first run is pretty slow, since everything has to be downloaded again. As cache key i use pom.xml, this is a good thing to do because it will on recache when dependencies actually change.

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?

Using 25-jdk , It would be easier and more maintenance friendly to use for both, but it would be slower for the ci/cd pipeline, it would be slower overall and use more cpu for no reason. It would have more negative impact then positive.

Using 25-jre for both, the build wouldn't even succeed, it doesn't have javac which is only in the jdk. So this will only be negative since nothing will work.

Gitlab-ci.yml structure:

The structure consists of 3 stages, maven-build, maven-container-image-generation and run-game. The first one builds the image (with dependencies from cache if possible), the second one generates the container the run the build in, and the third one runs logic-service and runs the build to test if the game works. This is done in 3 sequential stages (to ensure that stages dont fail prematurely because another one wasn't done yet). I made use of caching with pom.xml as key as i explained before, so that it will always cache dependencies and ONLY recaches when dependencies change. I use artifact for the maven-build stage with an expiry of 1hr.

I encountered lots of issues with caching, especially with trying to get the dependencies cached since it didn't want to find the .m2 repository, i fixed it by manually defining the RELATIVE path. I also experienced issues with the run-game where logic service had to be run before so that it could connect properly and wouldn't wait infinitely for player.

**Pipeline with caching: **https://gitlab.stud.atlantis.ugent.be/arthurheylbroeck/devops-project/-/pipelines/77549