管道和作业介绍

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

在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 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,B和C的联合将是(1,4)和(6,7),因此总运行时间应该是:

 

徽章

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

受保护分行的安全

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

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

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

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

帮助改进此翻译