Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

Tags:

gitlab

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.

like image 725
ILoveCode Avatar asked Aug 28 '20 12:08

ILoveCode


People also ask

What is the use of tags in GitLab CI Yml?

gitlab-ci. yml , you can specify some jobs with the tag testing . If a runner with this tag associated is available, it will pickup the job. In Git, within your repository, tags are used to mark a specific commit.

How do you trigger a pipeline on a merge request?

Push a new commit to the source branch for a merge request. Select Run pipeline from the Pipelines tab in a merge request. This option is only available when merge request pipelines are configured for the pipeline and the source branch has at least one commit.

What is hotfix in GitLab?

hotfix is meant to fix something in production. I think, we should instead a hotfix branch out of production branch. Then merge into master (which is the integration branch). After that, let production branch to cherry pick the commit from master.


1 Answers

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:.+$/
  1. .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
  1. 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

like image 53
ujlbu4 Avatar answered Sep 27 '22 21:09

ujlbu4