GitLab CI/CD Pipeline¶

Deployment-agnostic interpretation¶

Pipeline role: build and publish ${REGISTRY_HOST}/${ENTITY_NAMESPACE}/${CI_PROJECT_NAME}:${IMAGE_TAG}.

Current repo mapping:

• ${REGISTRY_HOST} -> HARBOR_HOST
• ${ENTITY_NAMESPACE} -> HARBOR_PROJECT
• ${IMAGE_TAG} -> CI_COMMIT_SHORT_SHA and latest

Source: .gitlab-ci.yml

Pipeline structure¶

• File: .gitlab-ci.yml
• Stages: build only
• Jobs: build only

Source: .gitlab-ci.yml

Job behavior¶

build¶

• Uses gcr.io/kaniko-project/executor:debug
• Disables container default entrypoint
• Creates /kaniko/.docker/config.json
• Authenticates against Harbor using HARBOR_USERNAME / HARBOR_PASSWORD
• Builds image from project Dockerfile
• Pushes both commit-SHA and latest image tags to Harbor

Build command:

/kaniko/executor \
  --context "${CI_PROJECT_DIR}" \
  --dockerfile "Dockerfile" \
  --destination "${HARBOR_HOST}/${HARBOR_PROJECT}/${CI_PROJECT_NAME}:${CI_COMMIT_SHORT_SHA}" \
  --destination "${HARBOR_HOST}/${HARBOR_PROJECT}/${CI_PROJECT_NAME}:latest"

Source: .gitlab-ci.yml

Rules, artifacts, dependencies¶

• Branch behavior: only: main
• Tag behavior: no tag-specific rule configured
• Artifacts: none
• needs/dependencies: none
• Deploy/promotion jobs: none

Source: .gitlab-ci.yml

Stage-by-stage explanation¶

Source: .gitlab-ci.yml

Release and promotion logic¶

Implemented:

• Images are tagged using CI_COMMIT_SHORT_SHA
• main also refreshes the mutable latest tag for existing deployment paths
• Every build produces an immutable image version

Not implemented in this pipeline:

• Multi-environment deployment (dev/staging/prod)
• Manual approval gates
• Helm deployment step
• Dedicated deployment stage

Source: .gitlab-ci.yml

Variables/secrets used by pipeline¶

Source: .gitlab-ci.yml

Assumptions¶

• Deployment happens in a separate pipeline/repository/tooling path because no deployment stage exists in this pipeline.