GitLab CI/CD流水线

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

流水线包括：

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

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

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

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

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

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

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

流水线类型

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

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

配置流水线

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

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

Ref specs for runners

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

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

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