GitLab CI/CD Pipeline¶
Deployment-agnostic interpretation¶
Pipeline role: build and publish ${REGISTRY_HOST}/${ENTITY_NAMESPACE}/${APP_SLUG}:${IMAGE_TAG}.
Current repo mapping:
${REGISTRY_HOST}->HARBOR_HOST${ENTITY_NAMESPACE}->HARBOR_PROJECT${APP_SLUG}-> hardcodedhello-world${IMAGE_TAG}->latest
Source: hello-world-main/.gitlab-ci.yml
Pipeline structure¶
- File:
hello-world-main/.gitlab-ci.yml - Stages:
buildonly - Jobs:
buildonly
Source: hello-world-main/.gitlab-ci.yml
Job behavior¶
build¶
- uses
docker:latestimage anddocker:dindservice - logs in to Harbor with username/password stdin
- builds image and pushes tag
- runs only for branch
main
Source: hello-world-main/.gitlab-ci.yml
Rules, artifacts, dependencies¶
- Branch behavior:
only: main - Tag behavior: no tag rule configured
- Artifacts: none
needs/dependencies: none- Deploy/promotion jobs: none
Source: hello-world-main/.gitlab-ci.yml
Stage-by-stage explanation¶
| Stage | Implemented jobs | Outcome |
|---|---|---|
build |
build |
publishes mutable image tag (latest) |
Source: hello-world-main/.gitlab-ci.yml
Release and promotion logic¶
Implemented:
- Promotion model is implicit: latest successful
mainbuild becomes deployable image.
Not implemented in this pipeline:
- immutable version tags
- multi-env deploy stages (dev/staging/prod)
- manual approval gates
- Helm deployment step
Source: hello-world-main/.gitlab-ci.yml
Variables/secrets used by pipeline¶
| Key | Secret? | Used by | Function |
|---|---|---|---|
HARBOR_HOST |
No | variables | registry host |
HARBOR_PROJECT |
No | variables | registry namespace/project |
HARBOR_USERNAME |
Yes | before_script |
registry auth user |
HARBOR_PASSWORD |
Yes | before_script |
registry auth pass/token |
TAG |
No | variables | image tag default (latest) |
Source: hello-world-main/.gitlab-ci.yml
Assumptions¶
- Deployment happens in a separate pipeline/repo/tooling path. Why: no deploy stage exists here.