查看“GitLab CI/CD流水线”的源代码

流水线是持续集成、交付和部署的顶级组件。

<br>

流水线包括：

* 工作，定义做什么。例如，编译或测试代码的作业。
* 阶段，定义何时运行作业。例如，在编译代码的阶段之后运行测试的阶段。

作业由 runners 执行。如果有足够多的并发运行程序，同一阶段的多个作业将并行执行。

<br>

如果一个阶段中的所有作业成功，流水线将进入下一个阶段。

如果某个阶段中的任何作业失败，则下一个阶段（通常）不会执行并且流水线提前结束。

一般来说，流水线是自动执行的，一旦创建就不需要干预。但是，有时您也可以手动与流水线交互。

<br>

一个典型的流水线可能包含四个阶段，按以下顺序执行：

* 一个 build 阶段，有一个名为 compile 的作业。
* 一个 test 阶段，有两个名为 test1 和 test2 的作业。
* 一个 staging 阶段，有一个名为 deploy-to-stage 的作业。
* 一个production阶段，有一个名为deploy-to-prod的作业。

<br>

== 流水线类型 ==

流水线可以通过多种不同的方式进行配置：

* 基本流水线：同时运行每个阶段的所有内容，然后是下一个阶段。
* 有向无环图 (DAG) 流水线：基于作业之间的关系，可以比基本流水线运行得更快。
* 多项目流水线：将不同项目的流水线组合在一起。
* 父子流水线：将复杂的流水线分解为一个可以触发多个子流水线的父流水线，这些子流水线都运行在同一个项目中并具有相同的 SHA。这种流水线架构通常用于 mono-repos。
* 合并请求的流水线：仅针对合并请求运行（而不是针对每次提交）。
* 合并结果的流水线：是来自源分支的更改已经合并到目标分支的合并请求流水线。
* 合并队列：使用合并结果流水线将合并一个接一个地排队

<br>

== 配置流水线 ==

流水线及其组件作业和阶段在每个项目的 CI/CD 流水线配置文件中定义。

* 作业是基本的配置组件。
* 阶段是使用 stages 关键字定义的。

<br>

<span id="ref-specs-for-runners"></span>
=== Ref specs for runners ===

当 runner 选择流水线作业时，系统会提供该作业的元数据，包括 Git refspecs，指示哪个引用（分支、标签等）和提交（SHA1) 从您的项目仓库中检出。

<br>

下表列出了为每种流水线类型注入的 refspecs：

{| class="wikitable"
|-
! 流水线类型
! Refspecs
|-
| 分支流水线
| +<sha>:refs/pipelines/<id> 和 +refs/heads/<name>:refs/remotes/origin/<name>
|-
| 标签流水线
| +<sha>:refs/pipelines/<id> 和 +refs/tags/<name>:refs/tags/<name>
|-
| 合并请求流水线
| +<sha>:refs/pipelines/<id>
|}

refs <code>refs/heads/&lt;name&gt;</code> 和 <code>refs/tags/&lt;name&gt;</code> 存在于您的项目仓库中。极狐GitLab 在运行流水线作业期间，生成特殊引用 refs/pipelines/<id>。即使在删除关联的分支或标记后，也可以创建此引用。因此，它在某些功能中很有用，例如自动停止环境和可能运行流水线的合并队列分支删除后。