【翻译】GitLab CI 管道和作业介绍

管道和作业介绍

官方文档：https://docs.gitlab.com/ee/ci...

在GitLab 8.8中引入的。

注意：如果你的项目是从GitLab中拉取的镜像仓库，需要在项目中开启触动开关

Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates.

管道

管道是一组分阶段（批处理）执行的工作。同一个阶段中的所有工作都是并行执行的（如果有足够的并发Runners），如果它们全部成功，管道就进入下一个阶段。如果其中一个jobs失败，则下一个阶段不（通常）执行。您可以访问项目的Pipeline选项卡中的管道页面。

在下图中，您可以看到管道由4个阶段组成（build(构建), test(测试), staging(分级), production(生产)），每个阶段都有一个或多个工作。

注意：在GitLab pipeline图上显示时，应当大写显示stats的名称。

管道类型

管道分三种，但是通常都使用单一的“管道”来代替所有。人们经常谈论他们，就好像每个都是“管道”一样，但实际上，他们只是综合管道的一部分。

1. CI Pipeline： 在gitlab-ci.yml中定义的构建和测试阶段。
2. Deploy Pipeline： 在.gitlab-ci.yml中定义的部署阶段，用来通过各种各样的方式将代码部署到服务器：

   例如，将代码发布到生成环境

3. Project Pipeline：通过API触发跨项目CI依赖关系，尤其是针对微服务，但也适用于复杂的构建依赖关系：

   例如，api-> front-end，ce / ee-> omnibus。

开发工作流程

管道适应多种开发工作流程：

1. Branch Flow（例如，dev，qa，分期，生产等不同分支）
2. Trunk-based Flow （例如，功能分支、单一的主分支和可能带有标签的发布）
3. 基于分叉的流程（例如，来自fork的合并请求）

连续交付流程示例：

工作

工作可以在.gitlab-ci.yml文件中定义。不要与build工作或build 阶段混淆。

定义管道

在.gitlab-ci.yml中通过指定阶段运行的作业来定义管道。

有关作业，请参阅参考文档。

查看管道状态

您可以在项目的 Pipeline选项卡下找到当前和历史运行的管道 。点击管道将显示为该管道运行的作业。

查看工作状态

当您访问单个管道时，您可以看到该管道的相关作业。点击单个作业会显示该作业运行历史，并允许您取消作业，重试作业或清除作业运行日志。

查看工作失败的原因

在GitLab 10.7中引入。

当管道发生故障或允许失败时，有几个地方可以快速检查失败的原因：

• 在管道图中 出现在管道图中。
• 在管道小部件中 出现在合并请求和提交页面中。
• 在工作视图中 出现在全局和详细的工作视图中。

无论任何方式中，你将鼠标悬停在失败的作业上，你可以看到失败的原因。

从GitLab 10.8中，您还可以在工作详情页面上看到失败的原因。

管道图

在GitLab 8.11中引入。

管道可以是复杂的结构，具有许多顺序和平行的作业。为了让您更容易看到发生了什么，它可以查看单个管道及其状态。

管道图可以通过两种不同的方式显示，具体取决于您所处的页面。

---

当您在单个管道页面上时，可以找到显示每个阶段作业名称的常规管道图。

其次，有管道迷你图，占用更少的空间，并且可以快速浏览所有作业是成果还是失败。管道迷你图可以在您访问以下页面时找到：

• 管道索引页面
• 提交页面
• 合并请求页面

通过这种方式，您可以看到所有相关的作业以及每个阶段的最终结果。这使您可以快速查看失败的工作并修复它。管道迷你图的阶段是可折叠的。将鼠标悬停在它们上面，然后单击以展开其他作业。

迷你图	迷你图展开

将相似的工作分组

在GitLab 8.12中引入。

如果你有许多类似的工作，你的管道图会变得很长，很难阅读。出于这个原因，类似的工作可以自动组合在一起。如果作业名称以某种格式命名，则它们将在常规管线图（非迷你图）中折叠为一个组。如果您没有看到重试或取消按钮，您就知道管道将作业已经合并分组了。将鼠标悬停在上面会显示分组作业的数量。可以点击展开它们。

基本要求是需使用以下方式的一种将两个数字分隔开（可以互换使用）（查看下面的示例）：

• 空间
• 斜线（/）
• 冒号（:）

注意： 更准确地说，它使用这个正则表达式：\d+[\s:\/\\]+\d+\s*。

这些工作将通过从左到右比较这两个数字来进行排序。通常第一个是索引，第二个是总数。

例如，以下作业将被分组在一个名为的作业下test：

• test 0 3 => test
• test 1 3 => test
• test 2 3 => test

以下作业将被分组在下列作业中test ruby：

• test 1:2 ruby => test ruby
• test 2:2 ruby => test ruby

下列作业也将被归类在一个作业中test ruby：

• 1/3 test ruby => test ruby
• 2/3 test ruby => test ruby
• 3/3 test ruby => test ruby

手动操作

在GitLab 8.15中引入。

手动操作允许您在使用CI中的指定作业之前需要手动操作。整个管道可以自动运行，但实际部署到生产需要点击。

您可以直接从管道图中做到这一点。只需点击播放按钮即可执行指定作业。例如，在下面的图片中，production 舞台上有一项手动操作。

作业排序

常规管道图

在单个管道页面中，作业按名称排序。

迷你管道图

在GitLab 9.0中引入。

在管道迷你图中，作业首先按重要性排序，然后按名称排序。重要性的顺序是：

• 失败
• 警告
• 有待
• 赛跑
• 手册
• 取消
• 成功
• 跳过
• 创建

多项目管道图

可在GitLab Premium 、GitLab Sliver或更高级版本中使用。

多项目管道，您可以访问跨项目管道。

如何计算管道持续时间

管道的总运行时间将排除重试和待处理（排队）时间。我们可以将这个问题缩减为寻找周期的联合。

所以每个工作都会被表示为 Period，其中包括 Period#first工作开始Period#last时和工作完成时。一个简单的例子是：

• A（1,3）
• B（2,4）
• C（6,7）

这里A从1开始，到3结束。B从2开始，并到4结束。C从6开始，到7结束。视觉上它可以被看作：

0  1  2  3  4  5  6  7
   AAAAAAA
      BBBBBBB
                  CCCC

A，B和C的联合将是（1,4）和（6,7），因此总运行时间应该是：

(4 - 1) + (7 - 6) => 4

徽章

管道状态和测试范围内报告徽章可用。您可以在管道设置页面找到它们各自的链接。

受保护分行的安全

管道在受保护的分支上执行时，将执行严格的安全模型 。

只有在允许用户合并或推送 特定分支时，才允许在受保护的分支上执行以下操作 ：

• 运行手动管道（使用Web UI或Pipelines API）
• 运行预定的管道
• 使用触发器运行管道
• 在现有管线上触发手动操作
• 重试/取消现有作业（使用Web UI或Pipelines API）

标记为受保护的变量仅适用于在受保护分支上运行的作业，从而避免不受信任的用户无意中访问敏感信息，如部署凭证和令牌。

标记为受保护的Runners只能保护分支机构运行的作业，避免不受信任的代码要在保护runner和保存部署键被意外地触发或其他凭证执行。为了确保打算在受保护的跑步者上执行的工作不会使用常规runner，必须对其进行相应标记。

帮助改进此翻译