Lab 1 Report

Questions

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

A: Mvnw is a script included within the repository. This way, contributors will be sure their build tools run the required version for that specific project rather than a global Maven install, also preventing any possible version mismatch. Every project can have their isolated version while developers shouldn't need to worry about installing the build tools. The only requirement is that the proper java runtime is installed, which is typically handled by the IDE anyway as the contributor will need it to work on the project.

Q: 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: A cache is used for shared dependencies between jobs and stages of a pipeline. It contains the required files from outside the project and can be reused across jobs as long as the files/dependencies don't change. This is needed since every stage's environment is cleaned before being run so these files would need to be redownloaded. Meanwhile, artifacts are used to share the resulting files between stages to prevent duplicate work. In order to package a project into a Docker container, it shouldn't need to compile the project again as it has probably already been compiled before to run integration tests. In short, caching is used to reuse dependencies in a way that prevents them from being needlessly cleaned and redownloaded every time, while artifacts are used to prevent doing the same work multiple times.

Q: 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?

A: In order to prevent wasting resources it's best to only use what's actually needed. In order to build a project, say in our CI/CD pipeline, we need tooling such as the compiler and debugging tools. These are bundled alongside the runtime (which is needed to run a project) in the JDK (Java Development Kit) and allows working on a project with a single kit. After a project has been compiled and needs to be deployed, say within a Docker container or on a client's desktop, these tools are no longer needed. Only the runtime is needed, which can be obtained from the JRE (Java Runtime Environment). So, using a JDK to run software will bundle unneeded tools and bring extra bloat at no added benefit (on the contrary: extra tools, even unused, bring their own vulnerabilities thus bringing their own attack vectors), while using a JRE to compile software will be impossible as the required tools would be missing.

CI/CD YAML structure

While most steps in the pipeline made sense, I did struggle with the execute stage where I couldn't manage to pull the the logic-service from the container registry. The reason for this was simply not knowing what the actual name of the container needed to be, as I had to include the $CI_REGISTRY predefined variable for example. What made this specific step more annoying was having to commit each time I changed the name to verify if it worked, resulting in have to wait for the pipeline to finish each time. This not only made me lose time, probably unnecessarily use up resources but also dirtied my commit history. I looked up what I could do in the future to remedy this:

A GitLab issue with recent activity pointed me to the fact you simply cannot run a pipeline without committing.
A Reddit thread pointed me to either working with a branch and squash/merging (which I'll definitely look into doing in the future - committing to main shouldn't really be done anyway) or by working with a local instance where I could freely test and only thereafter commit it to the remote repository.

Other than this, I feel like I didn't stray too much from the Lab assignment's YAML-structure. I did however look into keeping values as variables as well as GitLab's YAML Optimization guide.