How to version or tag incrementally in Gitlab CI/CD when merging from Production to Master branch

Question

I’m working on a project and I wanted to tag or give a version number. I wanted gitlab to tag V 1.0, 1.1, etc. in my gitci.yml file when the merging happens and my CI/CD runs successfully.

Quotidian

Answer 1

You could use for such purposes — semantic release tool. It automatically detects which version (major, minor, patch) to increment by commits prefixes. It can update not only gitlab tags, but ie send slack notifications, update version files or have any custom logic

example setup will look something like this (full example link will be at the end of answer)

1. .gitlab-ci.yml file

Build Release:
  image: node:dubnium
  stage: build release
  script:
    - npm i semantic-release @semantic-release/changelog @semantic-release/commit-analyzer @semantic-release/gitlab @semantic-release/git @semantic-release/npm @semantic-release/release-notes-generator semantic-release-slack-bot
    - npx semantic-release
  only:
    - master
  except:
    refs:
      - tags
    variables:
      - $CI_COMMIT_TITLE =~ /^RELEASE:.+$/

2. .releaserc.yaml file (at the same level as .gitlab-ci.yml)

branches: ['master']
ci: true
debug: true
dryRun: false
tagFormat: '${version}'

# Global plugin options (will be passed to all plugins)
preset: 'conventionalcommits'
gitlabUrl: 'http://gitlab.mycomany.com/' # your gitlab url
slackWebhook: 'https://slack.xxx.com/hooks/q3dtkec6yjyg9x6616o3atgkkr' # if you need slack notifies

# Responsible for verifying conditions necessary to proceed with the release:
# configuration is correct, authentication token are valid, etc...
verifyConditions:
  - '@semantic-release/changelog'
  - '@semantic-release/git'
  - '@semantic-release/gitlab'
  - 'semantic-release-slack-bot'

# Responsible for determining the type of the next release (major, minor or patch).
# If multiple plugins with a analyzeCommits step are defined, the release type will be
# the highest one among plugins output.
# Look details at: https://github.com/semantic-release/commit-analyzer#configuration
analyzeCommits:
  - path: '@semantic-release/commit-analyzer'

# Responsible for generating the content of the release note.
# If multiple plugins with a generateNotes step are defined,
# the release notes will be the result of the concatenation of each plugin output.
generateNotes:
  - path: '@semantic-release/release-notes-generator'
    writerOpts:
      groupBy: 'type'
      commitGroupsSort: 'title'
      commitsSort: 'header'
    linkCompare: true
    linkReferences: true

# Responsible for preparing the release, for example creating or updating files
# such as package.json, CHANGELOG.md, documentation or compiled assets
# and pushing a commit.
prepare:
  - path: '@semantic-release/changelog'
  - path: '@semantic-release/git'
    message: 'RELEASE: ${nextRelease.version}'
    assets: ['CHANGELOG.md']

# Responsible for publishing the release.
publish:
  - path: '@semantic-release/gitlab'

success:
  - path: 'semantic-release-slack-bot'
    notifyOnSuccess: true
    markdownReleaseNotes: false

fail:
  - path: 'semantic-release-slack-bot'
    notifyOnFail: true

3. to test it try make debug commit: $ git commit --allow-empty -m "fix: fake release" (will bump up path version)

---

Full working example is available here on gitlab

Foreman

Thanks @ujlbu. how about for the other services using other languages ? – Quotidian

@Quotidian this solution is language agnostic (doesn’t depend on a service language). You just need config file, appropriate git commit prefixes and command-line utility semantic-release – Foreman

@ujlbu4, Would it be possible to create gitlab pipeline build with a incremental build numbers like jenkins job,If yes Please let me know – Pires

@Pradeepkumar for incremental build number take a look at Predefined environment variables like CI_PIPELINE_ID or CI_JOB_ID. Btw, you don't need semantic-release tool from this post to use predefined env variables – Foreman

@Pradeepkumar the documentation lists variables that can be used, but not how they are actually used. Any idea where I can see an example implementation or documentation that shows that? – Protecting

Answer 2

Since npm provide version command to update version based on semantic versioning rule, we can add a stage in gitlab-ci.yml to increment version, commit, push and then continue with the CICD flow

Example:

stages:
  - unit-test
  - increment-version
  - other-steps

variables:
  # CI_REPOSITORY_URL contains gitlab-ci-token. replace start of the string up to '@'  with git@' and append a ':' before first '/'
  CI_REPOSITORY_URL=https://gitlab-ci-token:[email protected]/gitlab-examples/ci-debug-trace.git

before_script:
  - apk add --no-cache npm curl openssl

# unit-test or pre-increment goes here

increment-version:
  stage: increment-version
  scripts:
    - export PUSH_REPO=$(echo "$CI_REPOSITORY_URL" | sed -e "s|.*@\(.*\)|git@\1|" -e "s|/|:/|" )
    # increment PATCH, for instance
    - npm version patch
    - git add --all && git commit -m "auto-increment" 
    - git remote set-url --push origin "${PUSH_REPO}"
    - git push origin
  dependencies:
    - unit-test
   
# post-increment goes here

Reference: https://docs.npmjs.com/cli/v8/commands/npm-version

Overplus

Answer 3

For whoever in the future:

In short you create a CI/CD variable BUILD_NUMBER and start let say at 1, the you can use that variable in your job and update(increment) the variable of BUILD_NUMBER through curl from within the job, thus the need of generating an ACCESS_TOKEN and also keep it as a variable.

image: docker:latest

stages:
  - init

auto_increment:
 stage: init
 variables:
    VAR_NAME: BUILD_NUMBER
    TOKEN: ${CI_PIPELINE_IID_TOKEN}
    GITLAB_URL: "https://gitlab.com"
 before_script:
 - apk add --update curl jq
 script:
 - "VAR=$(curl -s -f  --header \"PRIVATE-TOKEN: ${TOKEN}\" \"${GITLAB_URL}/api/v4/projects/${CI_PROJECT_ID}/variables/${VAR_NAME}\" | jq  -r '.value' ) "
 - let VAR=VAR+1
 - "curl -s -f --request PUT --header \"PRIVATE-TOKEN: ${TOKEN}\" \"${GITLAB_URL}/api/v4/projects/${CI_PROJECT_ID}/variables/${VAR_NAME}\" --form \"value=${VAR}\" "

This was taken from here

Maidservant

I'm curious what this answer intended, given that the link requires a login. – Glassblowing

@Glassblowing The link doesn't require a login anymore! – Curvy

@Curvy I disagree. I am still redirected to gitlab.com/users/sign_in upon clicking the link. – Glassblowing

My apologies, you're right. I notice you can be logged in with any GitLab account (as I was), but you do have to be logged in. That's a shame. The page doesn't really show anything other than that GitLab user jmarcos.cano shared the code snippet above, and some discussion on where to add API keys in your project. – Curvy

Answer 4

# The release pipeline will run only if all jobs in the test pipeline are successful
stages:
  - test
  - release

before_script:
  - npm install

node:10:
  image: node:10
  stage: test
  script:
    - npm test

node:12:
  image: node:12
  stage: test
  script:
    - npm test

publish:
  image: node:12
  stage: release
  script:
    - npx semantic-release

For more information

https://semantic-release.gitbook.io/semantic-release/recipes/ci-configurations/gitlab-ci

Strachan