Help us learn about your current experience with the documentation. Take the survey.
发布 CI/CD 示例
GitLab 的发布功能非常灵活,可以配置以适应您的工作流程。本页面提供了 CI/CD 发布作业的示例。每个示例都演示了在 CI/CD 管道中创建发布的一种方法。
在创建 Git 标签时创建发布
在此 CI/CD 示例中,发布由以下任一事件触发:
- 将 Git 标签推送到仓库。
- 在用户界面 (UI) 中创建 Git 标签。
如果您更喜欢手动创建 Git 标签并以此创建发布,可以使用此方法。
在 UI 中创建 Git 标签时,请勿提供发布说明。提供发布说明会创建一个发布,导致管道失败。
以下示例 .gitlab-ci.yml 文件摘录中的要点:
rules部分定义了何时将作业添加到管道中。- Git 标签用于发布的名称和描述中。
release_job:
stage: release
image: registry.gitlab.com/gitlab-org/release-cli:latest
rules:
- if: $CI_COMMIT_TAG # 创建标签时运行此作业
script:
- echo "running release_job"
release: # 有关可用属性,请参阅 https://docs.gitlab.com/ee/ci/yaml/#release
tag_name: '$CI_COMMIT_TAG'
description: '$CI_COMMIT_TAG'在提交合并到默认分支时创建发布
在此 CI/CD 示例中,当您将提交合并到默认分支时,会触发发布。如果您的发布工作流程不手动创建标签,可以使用此方法。
以下示例 .gitlab-ci.yml 文件摘录中的要点:
- Git 标签、描述和引用在管道中自动创建。
- 如果您手动创建标签,
release_job作业不会运行。
release_job:
stage: release
image: registry.gitlab.com/gitlab-org/release-cli:latest
rules:
- if: $CI_COMMIT_TAG
when: never # 手动创建标签时不要运行此作业
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # 当提交被推送到或合并到默认分支时运行此作业
script:
- echo "running release_job for $TAG"
release: # 有关可用属性,请参阅 https://docs.gitlab.com/ee/ci/yaml/#release
tag_name: 'v0.$CI_PIPELINE_IID' # 版本号按管道递增。
description: 'v0.$CI_PIPELINE_IID'
ref: '$CI_COMMIT_SHA' # 标签是从管道 SHA 创建的。在 before_script 或 script 中设置的环境变量在同一作业中不可用于扩展。阅读更多关于可能使变量可用于扩展的信息。
在自定义脚本中创建发布元数据
在此 CI/CD 示例中,发布准备工作被拆分为独立的作业,以提供更大的灵活性:
prepare_job作业生成发布元数据。可以使用任何镜像来运行该作业,包括自定义镜像。生成的元数据存储在变量文件variables.env中。此元数据被传递给下游作业。release_job使用变量文件中的内容来创建发布,使用通过变量文件传递给它的元数据。此作业必须使用registry.gitlab.com/gitlab-org/release-cli:latest镜像,因为它包含发布 CLI。
prepare_job:
stage: prepare # 此阶段必须在发布阶段之前运行
rules:
- if: $CI_COMMIT_TAG
when: never # 手动创建标签时不要运行此作业
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # 当提交被推送到或合并到默认分支时运行此作业
script:
- echo "EXTRA_DESCRIPTION=some message" >> variables.env # 生成 EXTRA_DESCRIPTION 和 TAG 环境变量
- echo "TAG=v$(cat VERSION)" >> variables.env # 并追加到 variables.env 文件中
artifacts:
reports:
dotenv: variables.env # 使用 artifacts:reports:dotenv 将变量暴露给其他作业
release_job:
stage: release
image: registry.gitlab.com/gitlab-org/release-cli:latest
needs:
- job: prepare_job
artifacts: true
rules:
- if: $CI_COMMIT_TAG
when: never # 手动创建标签时不要运行此作业
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # 当提交被推送到或合并到默认分支时运行此作业
script:
- echo "running release_job for $TAG"
release:
name: 'Release $TAG'
description: 'Created using the release-cli $EXTRA_DESCRIPTION' # $EXTRA_DESCRIPTION 和 $TAG
tag_name: '$TAG' # 变量必须在管道中的其他地方定义
ref: '$CI_COMMIT_SHA' # 例如,在 prepare_job 中
milestones: #
- 'm1'
- 'm2'
- 'm3'
released_at: '2020-07-15T08:00:00Z' # 可选,如果未定义则自动生成,或可以使用变量。
assets:
links:
- name: 'asset1'
url: 'https://example.com/assets/1'
- name: 'asset2'
url: 'https://example.com/assets/2'
filepath: '/pretty/url/1' # 可选
link_type: 'other' # 可选创建发布时跳过多个管道
如果关联的标签尚不存在,使用 CI/CD 作业创建发布可能会触发多个管道。要了解这如何发生,请考虑以下工作流程:
-
先创建标签,后创建发布:
- 从 UI 创建标签或推送标签。
- 触发标签管道,并运行
release作业。 - 创建一个发布。
-
先创建发布,后创建标签:
- 当提交被推送到默认分支或合并到默认分支时,会触发一个管道。该管道运行
release作业。 - 创建一个发布。
- 创建一个标签。
- 触发标签管道。该管道也运行
release作业。
- 当提交被推送到默认分支或合并到默认分支时,会触发一个管道。该管道运行
在第二种工作流程中,release 作业在多个管道中运行。为防止这种情况,您可以使用 workflow:rules 关键字 来确定发布作业是否应在标签管道中运行:
release_job:
rules:
- if: $CI_COMMIT_TAG
when: never # 不要在标签管道中运行此作业
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # 当提交被推送到或合并到默认分支时运行此作业
script:
- echo "Create release"
release:
name: 'My awesome release'
tag_name: '$CI_COMMIT_TAG'