Lab 1 Report
What is ./mvnw and what is the advantage of using it above mvn?
It's 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. It checks if the specific version of Maven is available locally. If it's not, the script will download the correct version of Maven to run the project. You don't need to pre-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?
Cache is used to store data that doesn’t change frequently, like downloaded dependencies like Maven. This cache can be reused across different jobs and pipeline runs to avoid repetitive downloads. Artifacts are files produced by one job that can be passed to other jobs or stages.
Cache stored in repository are needed to speed up future pipelines by avoiding re-downloading the same packages from the internet in future pipelines. The trade-off is that the cache might become outdated, so it needs a periodic refresh.
Build files in target use artifacts. The target directory contains build outputs (compiled classes, packaged JARs,etc.) which must be passed from one job to another in the pipeline. It guarantees file transfer between jobs.
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?
JDK is a development kit that is necessary to build, debug, compile and run Java applications. JRE is needed to only run compiled Java applications. Using JDK for the CI/CD build jobs would significantly increase the image size because it would add unnecessary tools leading to higher storage cost and longer push and pull times. It would also decrease the security of the image. Using JRE for our runtime container would be not possible because it can't compile the project and the pipeline would fail.
A link to a successful run of the CI/CD job that executed the game.
Report on the structure of your .gitlab-ci.yml, detailing problems you encountered and how you solved them.
In the beginning I didn't quite understand how a yml file should look like. After seeing some examples on the internet I got my first job running. The package stage started crashing after the first job. I didn't understand how to debug it so I asked for some assistance. After some debugging I got my second job running. The pipeline kept running after the execute job. Correcting the variables resulted in passing. After some research I added and removed caches and artifacts to see what result it would have on the execute timer.