Skip to content

GitLab

An example YAML file for configuring Uplift to run on GitLab. To ensure Uplift can push changes back to your repository, you will need to provide it with a project or group access token1 with the write_repository permission.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# .gitlab-ci.yml

stages:
  - release

release:
  stage: release
  image:
    name: gembaadvantage/uplift
    entrypoint: [""]
  dependencies: [] # (1)
  before_script:
    - PROJECT_URL=${CI_PROJECT_URL#"https://"}
    - git remote set-url origin "https://oauth2:${GL_UPLIFT}@${PROJECT_URL}.git"
  variables:
    # Disable shallow cloning of repository
    GIT_DEPTH: 0
  script:
    # GitLab by default checks out a detached HEAD
    - git checkout $CI_COMMIT_REF_NAME
    - uplift release
  # Only run on the default branch of the repository
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      when: never
    - if: "$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH"
      when: on_success
  1. Prevents any dependencies, such as reports, from being unnecessarily copied into this job and causing the git checks to fail

To expose your access token within your pipeline you should add a CI/CD variable. In the above example, the access token is exposed through the GL_UPLIFT variable.

  1. It is best security practice to create an access token with the shortest possible expiration date. ↩