如何在从生产环境合并到主分支时在Gitlab CI/CD中递增版本号或标签

Question

如何在从生产环境合并到主分支时在Gitlab CI/CD中递增版本号或标签

gitgitlabversioninggit-taggitversion

17

我正在开展一个项目，希望为其打标签或者加版本号。当合并完成并且我的CI/CD成功运行时，我希望gitlab在我的gitci.yml文件中标记V 1.0、1.1等版本。

- ILoveCode

3个回答

1

由于npm提供了基于语义化版本规则更新版本的version命令，我们可以在gitlab-ci.yml中添加一个阶段来增加版本号、提交、推送，然后继续进行CICD流程。

例如：

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:xxxxxxxxxxxxxxxxxxxx@example.com/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

- blaz

-2

针对未来的任何人：

简而言之，您可以创建一个CI/CD变量BUILD_NUMBER并从1开始，然后您可以在作业中使用该变量，并通过curl从作业内部更新（增加）BUILD_NUMBER变量，因此需要生成ACCESS_TOKEN并将其保留为变量。

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}\" "

这是从这里获取的

- JeannotMn

我很好奇这个答案的意图，因为链接需要登录。 - qq4

@qq4 这个链接不再需要登录了！ - undefined

1

@Fons 我不同意。点击链接后，我仍然被重定向到https://gitlab.com/users/sign_in。 - undefined

抱歉，你是对的。我注意到你可以使用任何GitLab账户登录（就像我一样），但你确实需要已登录。真遗憾。该页面除了显示GitLab用户jmarcos.cano分享了上面的代码片段，还有一些关于在项目中添加API密钥的讨论，没有其他内容。 - undefined

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- ujlbu4 · Accepted Answer

你可以使用语义化版本管理工具 semantic release 来实现这种目的。它会自动根据提交信息中的前缀判断版本号应该增加哪个部分（major、minor或者patch）。它不仅可以更新 GitLab 的标签，还能发送 Slack 通知、更新版本文件或执行其他自定义逻辑。

一个示例设置将类似于下面这样（完整示例链接将在回答末尾提供）：

.gitlab-ci.yml 文件

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

.releaserc.yaml文件（与.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

要测试它，请尝试进行调试提交：$ git commit --allow-empty -m "fix: fake release"（将会提高路径版本）

完整的工作示例可在这里的GitLab上找到