代码即管道

GoCD 可以将流水线定义存储在代码仓库中（可以在应用程序的仓库中，或者在独立的仓库中）。这样，您可以将流水线定义移出 GoCD，并将其置于版本控制之下，进行外部管理。GoCD 服务器中的轮询器会定期检查外部流水线定义的修改，并将其与 GoCD 主 XML 配置文件中已存在的流水线数据合并。要快速了解此功能，请参阅此视频.

代码即管道是一个可选功能。任何现有的 GoCD 服务器配置仍将保持有效。

代码即管道允许 GoCD 监控并合并位于多个“配置仓库”中的外部流水线定义。来自配置仓库的流水线可能会依赖于 GoCD 主 XML 配置文件中定义的流水线。

代码即管道通过插件端点暴露，因此，您可以编写一个插件来以您选择的任何方式存储流水线配置数据。

下图显示了 GoCD 如何从多个来源组合流水线配置数据：

关于“基础设施即代码”的说明

“基础设施即代码”经常被等同于将配置数据提交到代码仓库。然而，GoCD 始终允许以多种形式通过代码进行配置。例如，gomatic，使用GoCD API, yagocd, gocd-cli，以及其他方式。代码即管道仅仅是多了一种选择。它使流水线定义更加声明化，具体取决于所使用的插件，并可能为外部维护者提供更多的控制。

用于存储管道作为代码的可用插件

JSON 和 YAML 是目前支持的两种格式。更多关于文件格式的信息，请参阅JSON 文件配置和YAML 文件配置。

配置仓库页面（Admin → Config Repositories）列出了现有的配置仓库，并允许对它们执行 CRUD（创建-读取-更新-删除）操作。该页面还会显示错误，并允许您请求检查某个配置仓库。

JSON 格式的管道配置

要告诉 GoCD 在哪里找到流水线配置文件：

• 启动服务器
• 转到“Admin → Config repositories”

• 点击右上角的“Add”按钮
• 选择“JSON configuration Plugin”作为插件 ID

添加配置仓库后，您将在流水线仪表板中看到新的流水线。如果有任何错误，您将看到上述提到的“Config repositories”页面上的错误。

YAML 格式的管道配置

要告诉 GoCD 在哪里找到流水线配置文件：

• 启动服务器
• 转到“Admin → Config repositories”

• 点击右上角的“Add”按钮
• 选择“YAML configuration Plugin”作为插件 ID

添加配置仓库后，您将在流水线仪表板中看到新的流水线。如果有任何错误，您将看到上述提到的“Config repositories”页面上的错误。

导出管道配置数据

从 GoCD19.1.0开始，您可以将流水线定义导出为配置仓库插件接受的格式（例如 YAML 或 JSON 插件）。然后，您可以将这些流水线定义提交到代码仓库，并将其从 GoCD 的主 XML 配置文件中移除。

指定规则

在 GoCD20.2.0之前，添加配置仓库意味着将 GoCD 的广泛控制权委托给能够推送至配置仓库的人。

这包括创建任意名称的流水线、在任意名称的流水线组中创建流水线、引用任意环境的流水线，以及可能恶意提取秘密的能力。由于 GoCD 和类似的系统本质上是任务运行器，此功能类似于在特权或受信任的环境中远程执行代码。

因此，在添加配置仓库时，您应格外小心，并对那些控制它们的人有适当的信任。

从 GoCD20.2.0开始，每个配置仓库必须明确授予对它可以影响或引用的 GoCD 实体的权限。

结构

第一条匹配的规则获胜，因此排序很重要。每条规则由三个核心部分组成 -指令, 类型和资源.

1) 指令

这可以是allow或deny，并决定规则的结果。

2) 类型

配置仓库规则可以适用于三种不同资源类型中的任何一种。

所有

您还可以通过指定*.

流水线组

当引用pipeline_group，这将允许或拒绝配置仓库在与给定名称或模式匹配的流水线组中创建流水线。资源.

您需要创建至少一条与所有预期将在目标配置仓库中引用的流水线组相匹配的规则。

管道

当引用pipeline，这将允许或拒绝配置仓库创建依赖于由资源名称或模式定义的其他流水线的流水线。资源，作为上游依赖材料。由于流水线依赖项需要从上游流水线获取/下载工件，这种规则类型还可以控制在不同配置仓库中定义的流水线之间的工件访问。

默认情况下，所有在同一配置仓库中定义的管道都将被允许相互引用（依赖）而不受限制，除非定义了规则。你可能需要额外的规则来允许你的管道依赖于其他配置仓库中定义的管道，以构建非平凡的价值流图（管道链/序列）。

环境

当引用一个environment，这将允许或拒绝配置仓库创建引用环境的管道匹配由资源.

指定的资源名称或模式。除非你在管道定义中使用该功能，为特定环境分配管道（和代理），否则你不需要定义环境规则。

3) 资源

这可以是任何字符串，并且用于匹配给定规则的名称资源的名称type.

注意，这是一个通用术语，与代理资源（用于允许提供给定资源的代理与需要它们的某些管道之间进行匹配）的概念无关。

你可以使用模式匹配：

• *作为任意通配符。
• ?作为单字符通配符。

操作

内部规则具有操作，这些操作可能因规则适用的资源类型而异。由于目前唯一支持的操作是refer（或*），此字段仅在内部可见。cruise-config.xml.

示例

假设有以下两个文件定义在两个不同的YAML 配置仓库中:

配置仓库 A

pipelines:
  repo-a-pipeline-one:
    group: pipeline-group-a
    materials:
      git:
        type: config-repo
  repo-a-pipeline-two:
    group: pipeline-group-a
    materials:
      git:
        type: config-repo
      upstream:
        pipeline: repo-a-pipeline-one
        stage: ...

配置仓库 B

pipelines:
  repo-b-pipeline-one:
    group: pipeline-group-b
    materials:
      git:
        type: config-repo
  repo-b-pipeline-two:
    group: another-pipeline-group-b
    materials:
      git:
        type: config-repo
      upstream-one:
        pipeline: repo-b-pipeline-one
        stage: ...
      upstream-two:
        pipeline: repo-a-pipeline-two
        stage: ...

无规则

<config-repo id="config-repo-a">
  ...
  <rules/>
</config-repo>

在没有任何规则的情况下，GoCD 将拒绝创建管道，因为配置仓库无法引用任何管道组。

允许一切（忽略安全性）

<config-repo id="config-repo-a">
  ...
  <rules>
    <allow action="refer" type="*">*</allow>
  </rules>
</config-repo>

<config-repo id="config-repo-b">
  ...
  <rules>
    <allow action="refer" type="*">*</allow>
  </rules>
</config-repo>

GoCD 将允许创建所有管道，因为配置仓库被允许引用任何名称的任何资源。这意味着对可以提交到给定配置仓库的用户有很高的信任度。

严格允许非平凡的 VSM

<config-repo id="config-repo-a">
  ...
  <rules>
    <!-- repo a only creates repos in `pipeline-group-a` -->
    <allow action="refer" type="pipeline_group">pipeline-group-a</allow>
  </rules>
</config-repo>

<config-repo id="config-repo-b">
  ...
  <rules>
    <!-- repo b creates a repo in `pipeline-group-b` -->
    <allow action="refer" type="pipeline_group">pipeline-group-b</allow>

    <!-- repo b also creates a repo in `another-pipeline-group-b` -->
    <allow action="refer" type="pipeline_group">another-pipeline-group-b</allow>

    <!-- repo b create a repo in that depends on a pipeline defined in another config repo so we must specify which -->  
    <allow action="refer" type="pipeline">repo-a-pipeline-two</allow>
  </rules>
</config-repo>

这些管道规则是配置管道所需的最严格的规则。

• config-repo-a必须被允许
  • 引用它所定义的管道组，pipeline-group-a
• config-repo-b必须被允许
  • 引用它所定义的管道组，pipeline-group-b和another-pipeline-group-b
  • 引用管道repo-a-pipeline-two因为它被定义为材料

规则顺序

当定义了多个权限时，规则将从上到下应用。

在下面的示例中，pipeline_grouppipeline-group-a 不可以被配置仓库引用，因为第一条规则使用模式拒绝访问pipeline-group-*

<rules>
  <deny action="refer" type="pipeline_group">pipeline-group-*</deny>
  <allow action="refer" type="pipeline_group">pipeline-group-a</allow>
</rules>

在下面的示例中，pipeline_grouppipeline-group-a 可以被配置仓库引用，因为第一条规则允许访问。

<rules>
  <allow action="refer" type="pipeline_group">pipeline-group-a</allow>
  <deny action="refer" type="pipeline_group">*</deny>
</rules>