如何使用Gitlab CICD发布工件（附实例）如何使用Gitlab CICD发布工件作者瓦伊巴夫-亚达夫on Au

如何使用Gitlab CICD发布工件

Gitlab工件

工作可以输出一个文件和目录的档案，这种输出被称为工作工件。

在这里了解更多关于Gitlab工件的信息。

Gitlab 发布

Gitlab 的发布与普通的软件发布没什么不同。它是一个特定软件的最终版本，在经过改进和错误修复后，向公众开放。

Gitlab 为我们提供了一些额外的选项，可以直接从仓库中创建/共享它们，从而使管理它们变得更加容易。

对于这篇博文，我们将采取一个NodeJS CLI应用程序。我们的目标是为Linux和Mac生成可执行文件作为工作成果，并将其作为发布文件发布。

我们将分两个阶段实现我们的目标：

生成工件
将工件发布为Gitlab版本

设置Gitlab CI

根据你是否想为默认分支以外的其他分支触发流水线，你可以在.gitlab-ci.yml 文件中设置一个工作流字段。你也可以根据你项目的要求来调整条件：

workflow:
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

接下来，添加缓存以使构建更快。我们在这个例子中对节点模块进行缓存：

cache:
  paths:
    - node_modules/

为了完成基本配置，我们在.gitlab-ci.yml 文件中添加两个阶段：

stages:
  - generate_executables
  - release

生成工件

gitlab-ci.yml 中的每个阶段在被运行器执行时都会被分配一个动态ID。这个ID也被称为工作ID。它可以通过预定义的CICD变量$CI_JOB_ID 。当我们发布工件时，我们将需要负责生成工件的阶段的工作ID。

在这里了解更多关于预定义的变量。

我们可以把这个值存储在一个.env 文件中，以便在下一个阶段读取它。

在将工作ID存储在.env 文件中后，我们执行命令来生成我们需要的工件文件：

generate_executables:
  stage: generate_executables
  image: node:16.6.1
  before_script:
    - echo $CI_JOB_ID
    # Writing GE_JOB_ID variable to environment file, will need the value in the next stage.
    - echo GE_JOB_ID=$CI_JOB_ID >> generate_executables.env
    - npm install
  script:
    # Commands responsible to generate the artifacts.
    - npm run pkg
    - echo "Executables generated successfully."
  artifacts:
    paths:
      # Should be relative to your root directory
      - dist/cloudwatch-linux
      - dist/cloudwatch-macos
    reports:
      # To ensure we've access to this file in the next stage
      dotenv: generate_executables.env
  only:
    # Can be removed if you want to trigger the pipeline for merge request or other branches
    - main

还记得我们谈到的工作ID吗？在artifacts 字段下，paths 决定哪些可执行文件需要被添加到作业工件中。我们使用reports:dotenv ，用于generate_executables.env 文件，其中包含release 阶段所需的工作ID。

发布工件

这个阶段依赖于Gitlab的发布CLI，需要安装在运行Gitlab runner的机器上。

点击这里了解更多关于Gitlab的发布CLI。

首先，注意在needs 字段中，我们提到它需要来自generate_executables 阶段的工件：

例子：

release:
  stage: release
  ...
needs:
  - job: generate_executables
    artifacts: true

了解更多关于将环境变量传递给另一个工作的信息，请点击这里。

再往下看release 字段，每次发布新版本时，名称应该是不同的。为了随时动态地改变名称字段的值，我使用了$CI_COMMIT_SHORT_SHA 。你也可以采用任何其他预定义的变量，或者也可以使用语义版本管理。如果是语义版本管理，你就必须在运行作业之前手动更新名称字段：

release:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  script:
    - echo 'running release_job'
    - echo 'Previous Job ID is printed below'
    - echo $GE_JOB_ID
  # Specifying that this job requires artifacts from the previous job to succeed
  needs:
    - job: generate_executables
      artifacts: true
  release:
    name: 'Release Executables $CI_COMMIT_SHORT_SHA'
    description: 'Created using the release-cli'
    # tag_name is a mendatory field and can not be an empty string
    tag_name: '$CI_COMMIT_SHORT_SHA'
    assets:
      links:
        - name: 'Linux executable'
          url: 'https://gitlab.com/codemancers/engineering/cw/-/jobs/${GE_JOB_ID}/artifacts/file/dist/cloudwatch-linux'
        - name: 'Mac executable'
          url: 'https://gitlab.com/codemancers/engineering/cw/-/jobs/${GE_JOB_ID}/artifacts/file/dist/cloudwatch-macos'
  only:
    # Can be removed if you want to trigger the pipeline for merge request or other branches
    - main

tag_name 字段不能是一个空字符串，也不能没有。牢记这一点。

第二阶段最重要的字段是assets 。在这里我们将使用我们在上一阶段存储在环境变量中的作业ID。正如你所看到的，在url 字段中，我们已经使用了变量为${GE_JOB_ID} ，以动态地获得生成工件的正确URL。

一旦工作成功，你可以从管道日志中得到发布页面的链接。或者，你可以访问你的版本库的主页，在那里你可以看到所有项目的发布链接，就在一个🚀火箭图标旁边。

PS: 在这个例子中，我们用bash作为Gitlab运行器的shell执行器。如果你使用的是docker或docker+machine执行器，则需要对URL的字符串插值进行调整。