您可以将流水线配置为在每次将更改提交到分支时运行。这种类型的流水线称为分支流水线。

或者，您可以将流水线配置为在每次更改合并请求的源分支时运行。这种类型的流水线称为合并请求流水线。

分支流水线：

当您将新提交推送到分支时运行。
是默认类型的流水线。
可以访问一些预定义的变量。
可以访问受保护的变量和受保护的 runners。

合并请求流水线：

默认情况下不运行。CI/CD 配置文件中的作业必须配置为在合并请求流水线中运行。
如果已配置，合并请求流水线会在您执行以下操作时运行：
- 从具有一个或多个提交的源分支创建新的合并请求。
- 将新提交推送到源分支以获取合并请求。
- 从合并请求的流水线选项卡中选择运行流水线。仅当配置合并请求流水线并且源分支至少有一个提交时，此选项才可用。
可以访问更多预定义变量。
无权访问受保护的变量或受保护的 runners。

合并请求的流水线类型

合并请求的三种流水线类型是：

合并请求流水线，它在合并请求的源分支中的更改上运行。
合并结果流水线，它运行在源分支的更改与目标分支的更改组合的结果上。
合并队列，在同时合并多个合并请求时运行。来自每个合并请求的更改与之前排队的合并请求中的更改合并到目标分支中，以确保它们一起生效。

先决条件

使用合并请求流水线：

您的项目的 CI/CD 配置文件，必须配置为在合并请求流水线中运行作业。为此，您可以使用：
- rules。
- only/except。
您必须至少在源项目中拥有开发人员角色才能运行合并请求的流水线。
您的仓库必须是 GitLab 仓库，而不是外部仓库。

使用 rules 添加作业

您可以使用 rules 关键字将作业配置为在合并请求的流水线中运行。例如：

job1:
  script:
    - echo "This job runs in merge request pipelines"
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'

您还可以使用 workflow: rules 关键字将整个流水线配置为在合并请求流水线中运行。例如：

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'

job1:
  script:
    - echo "This job runs in merge request pipelines"

job2:
  script:
    - echo "This job also runs in merge request pipelines"

使用 only 添加作业

您可以使用带有 merge_requests 的 only 关键字将作业配置为在合并请求的流水线中运行。

job1:
  script:
    - echo "This job runs in merge request pipelines"
  only:
    - merge_requests

GitLab 作业

流水线配置从作业开始。作业是 .gitlab-ci.yml 文件中最基本的元素。

作业是：

定义了约束条件，说明它们应该在什么条件下执行。
具有任意名称的顶级元素，并且必须至少包含 script 子句。
不限制可以定义的数量。

例如：

job1:
  script: "execute-script-for-job1"

job2:
  script: "execute-script-for-job2"

上面的示例是最简单的 CI/CD 配置，具有两个单独的作业，其中每个作业执行不同的命令。当然，命令可以直接执行代码（./configure;make;make install）或在仓库中运行脚本（test.sh）。

作业由 runners 拾取并在 runner 的环境中执行。重要的是，每个作业都是相互独立运行的。

流水线中分组作业

如果您有许多类似的作业，您的流水线图会变得很长且难以阅读。

您可以自动将相似的作业组合在一起。如果作业名称以某种方式格式化，它们将在常规流水线图（而不是迷你图）中折叠成一个组。

要创建一组作业，请在 CI/CD 流水线配置文件中，将每个作业名称用数字和以下之一分隔：

斜线（/），例如 slash-test 1/3、slash-test 2/3、slash-test 3/3。
冒号 (:)，例如 colon-test 1:3、colon-test 2:3、colon-test 3:3。
一个空格，例如 space-test 0 3、space-test 1 3、space-test 2 3。

您可以互换使用这些符号。

在下面的示例中，这三个作业位于名为 build ruby 的组中：

build ruby 1/3:
  stage: build
  script:
    - echo "ruby1"

build ruby 2/3:
  stage: build
  script:
    - echo "ruby2"

build ruby 3/3:
  stage: build
  script:
    - echo "ruby3"

流水线图显示了一个名为 build ruby 的组，其中包含三个作业。

通过从左到右比较数字来对作业进行排序。您通常希望第一个数字是索引，第二个数字是总数。

隐藏作业

要暂时禁用作业而不将其从配置文件中删除：

注释掉作业的配置：

  # hidden_job:
  #   script:
  #     - run test

以点（.）开头的作业名称，它不会被 GitLab CI/CD 处理：
```
  .hidden_job:
  script:
      - run test
```

您可以使用以 . 开头的隐藏作业作为可重用配置的模板：

extends 关键字。
YAML 锚点。

控制默认关键字和全局变量的继承

您可以控制以下事项的继承：

默认关键字和 inherit:default。
全局变量和 inherit:variables。

例如：

default:
  image: 'ruby:2.4'
  before_script:
    - echo Hello World

variables:
  DOMAIN: example.com
  WEBHOOK_URL: https://my-webhook.example.com

rubocop:
  inherit:
    default: false
    variables: false
  script: bundle exec rubocop

rspec:
  inherit:
    default: [image]
    variables: [WEBHOOK_URL]
  script: bundle exec rspec

capybara:
  inherit:
    variables: false
  script: bundle exec capybara

karma:
  inherit:
    default: true
    variables: [DOMAIN]
  script: karma

在这个例子中：

rubocop：
- 继承：没有。
rspec：
- 继承：默认的 image 和 WEBHOOK_URL 变量。
- 不继承：默认的 before_script 和DOMAIN 变量。
capybara：
- 继承：默认的 before_script 和image。
- 不继承：DOMAIN 和WEBHOOK_URL 变量。
karma：
- 继承：默认的 image 和before_script，以及 DOMAIN 变量。
- 不继承：WEBHOOK_URL 变量。

GitLab 合并请求的流水线

目录

合并请求的流水线类型

先决条件

使用 rules 添加作业

使用 only 添加作业

GitLab 作业

流水线中分组作业

隐藏作业

控制默认关键字和全局变量的继承

导航菜单

GitLab 合并请求的流水线

合并请求的流水线类型

先决条件

使用 rules 添加作业

使用 only 添加作业

GitLab 作业

流水线中分组作业

隐藏作业

控制默认关键字和全局变量的继承

导航菜单

搜索