【翻译】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，必须对其进行相应标记。

帮助改进此翻译