Builds, images and releases¶
The project produces a deliverable version by publishing one image per service to GitLab Container Registry. Although the thesis distinguishes Build and Release conceptually, the YAML performs both in the build stage; it has no GitLab Releases job or separate environment promotion job.
From source to JAR¶
generate-maven-jar uses maven:3.8.8-eclipse-temurin-17 and runs mvn clean package -DskipTests. Maven produces target/app.jar, following finalName in both POMs. The job keeps target/*.jar as an artifact, and generate-image receives it through needs with artifacts: true.
The shared YAML neither declares a Maven cache nor passes ci_settings.xml through -s. That file's presence does not prove use of GitLab's Maven registry. The JAR is not published to a Package Registry either: the job artifact is an input to Docker.
From JAR to image¶
generate-image uses Docker 29.2.1 and a matching Docker-in-Docker service. It signs in using GitLab-provided registry variables, builds the project's Dockerfile and pushes an image using this convention:
Example structure without credentials:
The SHA connects the image to source code. The registry tag is still a tag: no immutability policy has been verified, and manifests do not reference image digests. Dockerfiles also leave the base image unpinned by digest and update Alpine packages during each build. Rebuilding the same commit can produce a different image.
Runner requirements¶
The runner must support Docker-in-Docker and reach Maven Central, base image registries and GitLab Container Registry. Runner configuration, permissions and Docker connection/TLS variables are not versioned in this group. Validate the connection on the selected runner rather than assuming the Docker service declaration completes it.
Proposed improvements include passing registry credentials over stdin, pinning tool and base images by digest, and retaining image metadata. These are recommendations, not snapshot features.
What a delivery contains¶
| Evidence | Location |
|---|---|
| Application revision | Commit and pipeline in the source project |
| JAR | generate-maven-jar artifact while retained |
| Image | Container Registry and SHA tag |
| Manifest revision | Commit created by update-k8s-manifests |
| Application result | deploy job; supplement with rollout verification |
| Database | Separate state/backups; not encapsulated in the image |
Promotion between AWS and GKE selects another context, but no versioned mechanism guarantees promotion of the same digest to both destinations or coordinates frontend and backend versions. Each application can run its pipeline independently.
Post-build checks¶
Verify the expected JAR name, artifact download in the image job, container analysis of the same image path and SHA, and the image reference written into the manifest. If an artifact has expired, rebuild the necessary stage before retrying a dependent job.
For complete recovery, retain older images and review the rollback runbook, especially database schema compatibility.