Practical Guide to GitLab CI/CD Pipelines and Version Upgrade

GitLab Version Upgrade

Upgrade path: 12.9 → 12.10.14 → 13.0.0 → 13.8.4. Reference documentation and forum discussions are linked for detailed migration steps.

unning handlers:
Running handlers complete
Chef Infra Client finished, 441/1538 resources updated in 03 minutes 19 seconds
gitlab Reconfigured!
Checking for an omnibus managed postgresql: OK
Checking if postgresql['version'] is set: OK
Checking if we already upgraded: NOT OK
Checking for a newer version of PostgreSQL to install
Upgrading PostgreSQL to 12.5
Checking if PostgreSQL bin files are symlinked to the expected location: OK
cp /opt/gitlab/embedded/service/gitlab-rails/public/deploy.html /opt/gitlab/embedded/service/gitlab-rails/public/index.html
Toggling deploy page: OK
Toggling services:ok: down: alertmanager: 1s, normally up
ok: down: gitaly: 1s, normally up
ok: down: gitlab-exporter: 0s, normally up
ok: down: gitlab-pages: 1s, normally up
ok: down: grafana: 0s, normally up
ok: down: logrotate: 0s, normally up
ok: down: postgres-exporter: 1s, normally up
ok: down: prometheus: 0s, normally up
ok: down: redis-exporter: 1s, normally up
ok: down: sidekiq: 1s, normally up
ok: down: sshd: 0s, normally up
Toggling services: OK
Running stop on postgresql:ok: down: postgresql: 0s, normally up
Running stop on postgresql: OK
Symlink correct version of binaries: OK
Creating temporary data directory: OK
Initializing the new database: OK

New Features in 13.8 (CI/CD)

Control Job Status with Exit Codes

Use the allow_failure:exit_codes statement to dynamically allow specific exit codes without marking the job as failed.

test_job_1:
  script:
    - echo "Run a script that results in exit code 1. This job fails."
    - exit 1
  allow_failure:
    exit_codes: 137

test_job_2:
  script:
    - echo "Run a script that results in exit code 137. This job is allowed to fail."
    - exit 137
  allow_failure:
    exit_codes:
      - 137
      - 255

Reference: GitLab CI YAML documentation

Pipeline Rules Supporting Variables

The rules:variables feature (introduced in 13.7, enabled by default in 13.8) lets you define variables under specific rule conditions.

job:
  variables:
    DEPLOY_VARIABLE: "default-deploy"
  rules:
    - if: $CI_COMMIT_REF_NAME =~ /master/
      variables: # Override DEPLOY_VARIABLE defined at the job level.
        DEPLOY_VARIABLE: "deploy-production"
    - if: $CI_COMMIT_REF_NAME =~ /feature/
      variables:
        IS_A_FEATURE: "true" # Define a new variable.
  script:
    - echo "Run script with $DEPLOY_VARIABLE as an argument"
    - echo "Run another script if $IS_A_FEATURE exists"

Reference: GitLab CI YAML documentation

Docker Executor Pull Policy

The pull_policy parameter allows specifying a list of image pull strategies that are tried in order until a pull succeeds.

When a Docker registry is unavailable, using the always policy alone can cause job failure even if the image is cached locally. Adding if-not-present as a fallback lets the runner use cached layers.

[runners.docker]
  pull_policy = ["always", "if-not-present"]

Project Configuration for Keeping Latest Artifacts

By default, the latest artifacts from the most recent successful job are never deleted. If you set expire_in on a job, its artifacts expire only when newer artifacts exist.

Retaining latest artifacts can consume significant storage for large projects. To disable this behavior:

Navigate to Settings > CI/CD > Artifacts .

Uncheck “Keep artifacts from the most recent successful job”.

You can also disable this globally for all projects on a self‑managed instance via the instance CI/CD settings. After disabling, the latest artifacts will only expire after a new pipeline runs.

Predefined Variables for Branch and Merge Requests

GitLab 13.8 adds two predefined variables:

CI_PROJECT_CONFIG_PATH – specifies the path to the project's CI configuration file.

CI_OPEN_MERGE_REQUESTS – a comma‑separated list (up to four) of open merge requests that use the current branch as the source, e.g., gitlab-org/gitlab!333,gitlab-org/gitlab-foss!11 .

Pipeline Configuration Visualization

To view a visual representation of the gitlab-ci.yml configuration, go to CI / CD > Editor in the project and select the **Visualization** tab. The diagram shows all stages, jobs, and any needs relationships as connecting lines.

Hover over a job to highlight its needs relationships. If no needs are defined, jobs are linked only by sequential stage execution.

Feature.disable(:ci_pipeline_editor_page)
Feature.enable(:ci_pipeline_editor_page)

About Us

Zeyang, a DevOps practitioner, focuses on enterprise‑level DevOps operations and development techniques. He shares practical experience through courses that emphasize real‑world applicability, covering new Linux operations, DevOps tools, and hands‑on training. Follow the DevOps pipeline practice course for more learning resources.