Skip to content

CI additions

These focused additions support the pipelines from Lab 2, Lab 4, and Lab 5. They are not a separate assignment.

Use course image mirrors

The course mirrors provide Lab 4's deployment tooling and PostgreSQL images without pulling from Docker Hub. Merge these image settings into your existing jobs; keep their scripts and rules:

deploy-staging:
  image: gitlab.stud.atlantis.ugent.be:5050/devops/images/k8s:1.36.5

verify-postgres:
  services:
    - name: gitlab.stud.atlantis.ugent.be:5050/devops/images/postgres:18.6
      alias: postgres

Keep the postgres alias so your JDBC URL remains jdbc:postgresql://postgres:5432/colonyops. The PostgreSQL companion uses the same registry for local PostgreSQL, pgAdmin, and the staging Helm chart and image. Do not prefix these GitLab URLs with a Dependency Proxy variable. Your own published logic-service images stay in your project's Container Registry. If mirror access fails, check with staff rather than adding a personal token to the pipeline.

Cache Docker Hub images with the Dependency Proxy

For other Docker Hub images, GitLab's Dependency Proxy caches pulls for a group, reducing downloads and the chance of hitting Docker Hub's pull rate limit. Prefix image names with ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/. GitLab supplies this variable, and the runner authenticates automatically for image: and services: pulls: no personal token or extra docker login job is needed. For example, Lab 2's verification image can use:

verify:
  image: ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/eclipse-temurin:25.0.4.1_1-jdk-noble

Keep version tags pinned; caching is not a reason to use latest.

  • CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX uses the top-level group cache. CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX instead uses your project's direct group.
  • This applies to Docker Hub images, not GitLab-hosted images or charts. It does not automatically redirect local Docker pulls, Helm OCI downloads, Kubernetes node pulls, or Jib's own base-image fetches.
  • The first uncached pull still needs Docker Hub. If proxy access is denied, check with staff rather than adding a personal access token to the pipeline.

See GitLab's CI authentication and predefined variables and rate-limit explanation.

Check job rules without publishing a tag

Lab 2's tag pipeline publishes a release image and updates latest. Do not push a throwaway tag just to check that Lab 4's staging deployment is excluded.

Inspect a real MR pipeline's job list. For the default-branch and tag cases, use GitLab's pipeline editor validation or CI Lint API pipeline simulation. Validate your current configuration in the chosen branch/tag context, not an old tag's YAML from before the deploy job existed. Use an existing ref and inspect the included jobs.

For a command-line starting point, authenticate glab to the course GitLab instance. Run this from your project repository, with jq available, to submit your current local CI configuration:

REF=main # Replace with an existing branch or tag to check.
jq -n --rawfile content .gitlab-ci.yml --arg ref "$REF" \
  '{content: $content, dry_run: true, include_jobs: true, ref: $ref}' > /tmp/ci-lint.json
glab api --method POST 'projects/:id/ci/lint' --input /tmp/ci-lint.json \
  | jq '{valid, errors, jobs: [.jobs[]?.name]}'

include_jobs: true requests the job list; a syntax-only check is insufficient. Inspect valid and errors before interpreting an empty list. The ref must already exist on GitLab. Do not create a throwaway release tag to satisfy this requirement: in Lab 5, the real first v0.1.0 pipeline can prove the positive version-tag case. Use an existing non-version tag to check exclusion against the final configuration. In Lab 4, all tag cases exclude staging; in Lab 5, only version tags include production. Neither includes staging.

Check job selection, not just YAML syntax. Simulation does not deploy anything or prove the deployment commands work; the successful default-branch pipeline is the separate check for that.