CI/CD 组件
Tier: 基础版，专业版，旗舰版
Offering: JihuLab.com，私有化部署
版本历史
CI/CD 组件是一个可复用的单一流水线配置单元。使用组件来创建大型流水线的一小部分，甚至组合出完整的流水线配置。
组件可以配置输入参数以获得更动态的行为。
CI/CD 组件类似于使用 include 关键字添加的其他配置，但有几个优势：
- 组件可以列在 CI/CD 目录中。
- 组件可以发布并使用特定版本。
- 多个组件可以在同一个项目中定义并一起进行版本管理。
除了创建自己的组件，您还可以在 CI/CD 目录中搜索具有您所需功能的已发布组件。
有关常见问题和其他支持，请参见 常见问题：极狐GitLab CI/CD 目录 博客文章。
组件项目
版本历史
- 每个项目的最大组件数量在 极狐GitLab 16.9 中从 10 个更改为 30 个。
- 每个项目的最大组件数量在 极狐GitLab 18.5 中从 30 个更改为 100 个。
组件项目是一个带有仓库的 GitLab 项目，该仓库托管一个或多个组件。项目中的所有组件一起进行版本管理，每个项目最多 30 个组件。
如果某个组件需要与其他组件不同的版本管理，该组件应移至专用的组件项目。
创建组件项目
要创建组件项目，您必须：
-
- 确保描述清楚地介绍该组件。
- 可选。项目创建后，您可以添加项目头像。
发布到 CI/CD 目录的组件在显示组件项目摘要时会使用描述和头像。
-
按照要求的目录结构为每个组件添加一个 YAML 配置文件。 例如：
yaml1spec: 2 inputs: 3 stage: 4 default: test 5--- 6component-job: 7 script: echo job 1 8 stage: $[[ inputs.stage ]]
您可以立即使用该组件，但您可能还需要考虑将其发布到 CI/CD 目录。
目录结构
仓库必须包含：
- 一份 README.md Markdown 文件，记录仓库中所有组件的详细信息。
- 一个顶层的 templates/ 目录，包含所有组件配置。
在此目录中，您可以：
- 为每个组件使用以 .yml 结尾的单一文件，例如 templates/secret-detection.yml。
- 为每个组件创建包含 template.yml 的子目录，例如 templates/secret-detection/template.yml。只有 template.yml 文件会被其他使用该组件的项目所使用。这些目录中的其他文件不会随组件一起发布，但可用于诸如测试或构建容器镜像等目的。
您还应该：
- 配置项目的 .gitlab-ci.yml 以测试组件和发布新版本。
- 添加一个 LICENSE.md 文件，包含您选择的许可证，涵盖组件的使用。例如，MIT 或 Apache 2.0 开源许可证。
例如：
-
如果项目包含单个组件，目录结构应类似于：
plaintext├── templates/ │ └── my-component.yml ├── LICENSE.md ├── README.md └── .gitlab-ci.yml -
如果项目包含多个组件，则目录结构应类似于：
plaintext1├── templates/ 2│ ├── my-component.yml 3│ └── my-other-component/ 4│ ├── template.yml 5│ ├── Dockerfile 6│ └── test.sh 7├── LICENSE.md 8├── README.md 9└── .gitlab-ci.yml在此示例中：
- my-component 组件的配置在单一文件中定义。
- my-other-component 组件的配置包含目录中的多个文件。只有 template.yml 文件可以被其他使用该组件的项目所使用。
使用组件
先决条件：
如果您是包含当前群组或项目的父群组成员：
- 您必须拥有由项目父群组的可见性级别所设置的最低角色。例如，如果父项目设置为私有，您必须具有报告者、开发者、维护者或所有者角色。
要将组件添加到项目的 CI/CD 配置中，请使用 include: component 关键字。组件引用格式为 <fully-qualified-domain-name>/<project-path>/<component-name>@<specific-version>，例如：
yamlinclude: - component: $CI_SERVER_FQDN/my-org/security-components/secret-detection@1.0.0 inputs: stage: build
在此示例中：
- $CI_SERVER_FQDN 是匹配 极狐GitLab 主机的完全限定域名（FQDN）的预定义变量。您只能引用与您的项目位于同一 极狐GitLab 实例中的组件。
- my-org/security-components 是包含组件的项目的完整路径。
- secret-detection 是组件名称，定义为单一文件 templates/secret-detection.yml 或包含 template.yml 的目录 templates/secret-detection/。
- 1.0.0 是组件的版本。
流水线配置和组件配置不会被独立处理。当流水线启动时，任何包含的组件配置会合并到流水线配置中。如果您的流水线和组件都包含同名配置，它们可能会以意想不到的方式交互。
例如，两个同名的作业会合并为一个作业。类似地，一个使用 extends 的组件如果与您流水线中的作业配置同名，可能会扩展错误的配置。请确保您的流水线和组件不共享任何同名配置，除非您有意覆盖组件的配置。
要在私有化部署实例上使用 JihuLab.com 组件，您必须镜像组件项目。
组件版本
按最高优先顺序排列，组件版本可以是：
- 提交 SHA，例如 e3262fdd0914fa823210cdb79a8c421e2cef79d8。
- 标签，例如 1.0.0。如果存在同名标签和提交 SHA，则提交 SHA 优先于标签。发布到 CI/CD 目录的组件必须使用语义版本进行标记。
- 分支名称，例如 main。如果存在同名分支和标签，标签优先于分支。
- ~latest 或部分语义版本，用于选择在 CI/CD 目录中发布的指定模式内的最新版本。只有在希望始终使用绝对最新版本（可能包含破坏性更改）时才使用 ~latest。~latest 不包括预发布版本，例如 1.0.1-rc，这些版本不被视为可投入生产。
您可以使用组件支持的任何版本，但建议使用发布到 CI/CD 目录的版本。通过提交 SHA 或分支名称引用的版本可能未发布在 CI/CD 目录中，但可用于测试。
部分语义版本
版本历史
- 在 极狐GitLab 16.11 中引入。
在引用 CI/CD 目录组件时，您可以使用部分语义版本号和关键字 ~latest 来选择与您的规格匹配的最新发布版本。
这些格式仅适用于已发布的 CI/CD 目录组件，不适用于常规项目组件。这确保了当您使用类似 1.2 或 ~latest 的格式时，只会拉取已经验证并发布到目录的组件，而不是来自任何仓库的潜在未测试代码。
这种方法为组件的使用者和作者都带来了显著的好处：
- 对于使用者，使用部分版本是自动接收次要或补丁更新的绝佳方式，而不会面临来自主要版本的破坏性更改风险。这确保您的流水线在保持稳定性的同时，始终获得最新的错误修复和安全补丁。
- 对于组件作者，部分版本支持允许发布主要版本，而不会立刻破坏现有流水线。指定了部分版本的用户将继续使用最新的兼容次要或补丁版本，从而能够按照自己的节奏更新流水线。
使用：
- 1.2 选择最新的 1.2.* 版本
- 1 选择最新的 1.*.* 版本
- ~latest 选择最新的已发布版本
例如，一个组件有如下版本：1.0.0、1.1.0、1.1.1、1.2.0、2.0.0、2.0.1、2.1.0
当引用该组件时：
- 1 选择 1.2.0
- 1.1 选择 1.1.1
- ~latest 选择 2.1.0
使用部分版本选择时，永远不会获取预发布版本。要获取预发布版本，请指定完整版本，例如 1.0.1-rc。
在组件中使用组件上下文
版本历史
组件可以通过组件上下文 CI/CD 表达式 访问有关自身的元数据。在组件模板中使用此表达式来动态引用版本、提交 SHA 和其他元数据。
要在组件中使用组件上下文，您必须：
- 在 spec:component 头部中声明组件需要哪些组件上下文字段。spec:component 支持 name、sha、version 和 reference 字段。
- 在组件模板中使用 CI/CD 表达式 $[[ component.field-name ]] 引用上下文字段。
例如，一个引用使用相同版本构建的 Docker 镜像的组件：
yaml1spec: 2 component: [name, version, reference] 3 inputs: 4 stage: 5 default: build 6--- 7 8build-image: 9 stage: $[[ inputs.stage ]] 10 image: registry.example.com/$[[ component.name ]]:$[[ component.version ]] 11 script: 12 - echo "Building with component version $[[ component.version ]]" 13 - echo "Component reference: $[[ component.reference ]]"
您还可以使用组件上下文来引用版本化资源。
组件 spec 部分
组件模板中的 spec 部分定义了组件的配置和输入。您可以在 spec 部分使用以下关键字：
- description：提供组件在 CI/CD 目录中显示的简短描述。
- inputs：定义供用户自定义组件配置的输入参数。
- component：声明哪些组件上下文字段可用于插值（如 name、sha、version 和 reference）。
编写组件
本节介绍创建高质量组件项目的一些最佳实践。
管理依赖
虽然组件可能反过来使用其他组件，但请仔细选择依赖项。要管理依赖项，您应该：
- 将依赖项保持在最低限度。少量重复通常优于拥有依赖项。
- 尽可能依赖本地依赖项。例如，使用 include:local 是确保跨多个文件使用相同 Git SHA 的好方法。
- 当依赖其他项目的组件时，将其版本固定为目录中的某个发布版本，而不是使用诸如 ~latest 或 Git 引用这样的移动目标版本。使用发布版本或 Git SHA 可以确保您每次获取相同的修订版本，并且您组件的用户也能获得一致的行为。
- 通过将依赖项固定到更新的版本来定期更新它们。然后使用更新后的依赖项发布组件的新版本。
- 评估依赖项的权限，并使用需要最少权限的依赖项。例如，如果您需要构建镜像，请考虑使用 Buildah 而不是 Docker，这样您就不需要拥有特权 Docker 守护进程的 Runner。
编写清晰的 README.md
每个组件项目应具有清晰且全面的文档。要编写良好的 README.md 文件：
- 从组件提供的功能摘要开始。
- 如果项目包含多个组件，使用目录帮助用户快速跳转到特定组件的详细信息。
- 添加一个 ## 组件 部分，并为每个组件设置如 ### 组件 A 的子部分。
- 在每个组件部分中：
- 描述组件的作用。
- 至少添加一个展示如何使用它的 YAML 示例。
- 使用 spec:inputs:description 记录组件使用的任何变量或密钥。
- 不要在 README 中重复输入文档。输入会自动显示在组件页面上。相反，应链接到已发布的组件。
- 如果欢迎贡献，添加一个 ## 贡献 部分。
如果一个组件需要更多说明，请在组件目录中添加额外的 Markdown 文件，并从主 README.md 文件链接到它。例如：
plaintext1README.md # 带有指向特定 docs.md 的链接 2templates/ 3├── component-1/ 4│ ├── template.yml 5│ └── docs.md 6└── component-2/ 7 ├── template.yml 8 └── docs.md
有关示例，请参见 AWS 组件 README。
测试组件
强烈建议在开发工作流中测试 CI/CD 组件，这有助于确保一致的行为。
通过在根目录中创建 .gitlab-ci.yml 来在 CI/CD 流水线中测试更改（与其他项目一样）。确保测试组件的行为和潜在的副作用。如果需要，您可以使用 极狐GitLab API。
例如：
yaml1include: 2 # 包含当前项目中基于当前提交 SHA 的组件 3 - component: $CI_SERVER_FQDN/$CI_PROJECT_PATH/my-component@$CI_COMMIT_SHA 4 inputs: 5 stage: build 6 7stages: [build, test, release] 8 9# 检查是否添加了 my-component 的组件作业。 10# 此示例作业还可以测试所包含的组件是否按预期工作。 11# 您可以检查组件生成的数据，使用 极狐GitLab API 端点或第三方工具。 12ensure-job-added: 13 stage: test 14 image: badouralix/curl-jq 15 # 将 "组件作业 my-component" 替换为您组件中的作业名称。 16 script: 17 - | 18 route="${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/pipelines/${CI_PIPELINE_ID}/jobs" 19 count=`curl --silent --header "JOB-TOKEN: ${CI_JOB_TOKEN}" "$route" | jq 'map(select(.name | contains("组件作业 my-component"))) | length'` 20 if [ "$count" != "1" ]; then 21 exit 1; else 22 echo "组件作业已存在" 23 fi 24 25# 如果流水线是针对具有语义版本的新标签，并且所有前面的作业都成功， 26# 则创建发布。 27create-release: 28 stage: release 29 image: registry.gitlab.com/gitlab-org/cli:latest 30 script: echo "Creating release $CI_COMMIT_TAG" 31 rules: 32 - if: $CI_COMMIT_TAG 33 release: 34 tag_name: $CI_COMMIT_TAG 35 description: "Release $CI_COMMIT_TAG of components repository $CI_PROJECT_PATH"
在提交并推送更改后，流水线会测试组件，然后在更早的作业通过后创建发布。
使用示例文件测试组件
在某些情况下，组件需要源文件来交互。例如，一个构建 Go 源代码的组件可能需要一些 Go 示例来进行测试。或者，一个构建 Docker 镜像的组件可能需要一些示例 Dockerfile 来进行测试。
您可以直接在组件项目中包含此类示例文件，以便在组件测试期间使用。
您可以在测试组件的示例中了解更多信息。
避免硬编码实例或项目特定的值
当在您的组件中使用另一个组件时，请使用 $CI_SERVER_FQDN 而不是您实例的完全限定域名（如 gitlab.com）。
当在组件中访问 极狐GitLab API 时，请使用 $CI_API_V4_URL 而不是您实例的完整 URL 和路径（如 https://gitlab.com/api/v4）。
这些预定义变量确保您的组件在其他实例上也能正常工作，例如在私有化部署实例上使用 JihuLab.com 组件时。
不要假定 API 资源始终是公开的
确保组件及其测试流水线也能在私有化部署上工作。虽然 JihuLab.com 上公共项目的某些 API 资源可以通过未经身份验证的请求访问，但在私有化部署实例上，组件项目可能被镜像为私有或内部项目。
重要的是，可以选择通过输入或变量提供访问令牌，以便在私有化部署实例上对请求进行身份验证。
避免使用全局关键字
避免在组件中使用全局关键字。在组件中使用这些关键字会影响流水线中的所有作业，包括直接在主 .gitlab-ci.yml 或其他包含的组件中定义的作业。
作为全局关键字的替代方案：
- 将配置直接添加到每个作业，即使这会在组件配置中造成一些重复。
- 在组件中使用 extends 关键字，但要使用唯一的名称，以降低组件合并到配置中时发生命名冲突的风险。
例如，避免使用 default 全局关键字：
yaml1# 不推荐 2default: 3 image: ruby:3.0 4 5rspec-1: 6 script: bundle exec rspec dir1/ 7 8rspec-2: 9 script: bundle exec rspec dir2/
相反，您可以：
-
将配置显式添加到每个作业：
yaml1rspec-1: 2 image: ruby:3.0 3 script: bundle exec rspec dir1/ 4 5rspec-2: 6 image: ruby:3.0 7 script: bundle exec rspec dir2/ -
使用 extends 重用配置：
yaml1.rspec-image: 2 image: ruby:3.0 3 4rspec-1: 5 extends: 6 - .rspec-image 7 script: bundle exec rspec dir1/ 8 9rspec-2: 10 extends: 11 - .rspec-image 12 script: bundle exec rspec dir2/
用输入替换硬编码值
避免在 CI/CD 组件中使用硬编码值。硬编码值可能会迫使组件用户需要审查组件的内部细节并调整其流水线以配合组件工作。
一个常见的存在问题的硬编码值是 stage。如果组件作业的阶段是硬编码的，所有使用该组件的流水线必须要么定义完全相同的阶段，要么覆盖该配置。
推荐的方法是使用 input 关键字实现动态组件配置。组件用户可以指定他们所需的确切值。
例如，创建一个用户可以定义 stage 配置的组件：
-
在组件配置中：
yaml1spec: 2 inputs: 3 stage: 4 default: test 5--- 6unit-test: 7 stage: $[[ inputs.stage ]] 8 script: echo unit tests 9 10integration-test: 11 stage: $[[ inputs.stage ]] 12 script: echo integration tests -
在使用该组件的项目中：
yaml1stages: [verify, release] 2 3include: 4 - component: $CI_SERVER_FQDN/myorg/ruby/test@1.0.0 5 inputs: 6 stage: verify
使用输入定义作业名称
与 stage 关键字的值类似，您应避免在 CI/CD 组件中硬编码作业名称。当您的组件用户可以自定义作业名称时，他们可以防止与流水线中现有名称发生冲突。用户还可以通过使用不同的名称多次包含同一个组件，并采用不同的输入选项。
使用 inputs 允许您的组件用户定义一个具体的作业名称，或作业名称的前缀。例如：
yaml1spec: 2 inputs: 3 job-prefix: 4 description: "定义作业名称的前缀" 5 job-name: 6 description: "或者，定义作业的名称" 7 job-stage: 8 default: test 9--- 10 11"$[[ inputs.job-prefix ]]-scan-website": 12 stage: $[[ inputs.job-stage ]] 13 script: 14 - scan-website-1 15 16"$[[ inputs.job-name ]]": 17 stage: $[[ inputs.job-stage ]] 18 script: 19 - scan-website-2
用输入替换自定义 CI/CD 变量
当在组件中使用 CI/CD 变量时，评估是否应改用 inputs 关键字。避免要求用户定义自定义变量来配置组件，当 inputs 是更好的解决方案时。
（由于输入被截断，这是第 1 部分结束，但内容已完成当前部分）
输入在组件的 spec 部分中明确定义，并且比变量具有更好的验证。 例如，如果未将必需的输入传递给组件，极狐GitLab 会返回流水线错误。 相比之下，如果未定义变量，则其值为空，并且没有错误。
例如，使用 inputs 而不是变量来配置扫描器的输出格式：
-
在组件配置中：
yaml1spec: 2 inputs: 3 scanner-output: 4 default: json 5--- 6my-scanner: 7 script: my-scan --output $[[ inputs.scanner-output ]] -
在使用该组件的项目中：
yamlinclude: - component: $CI_SERVER_FQDN/path/to/project/my-scanner@1.0.0 inputs: scanner-output: yaml
在其他情况下，CI/CD 变量可能仍然是首选。例如：
- 使用 预定义变量 自动配置组件以匹配用户的项目。
- 要求用户将敏感值存储为项目设置中的 掩码或受保护的 CI/CD 变量。
CI/CD Catalog
Tier: 基础版，专业版，旗舰版
Offering: JihuLab.com，私有化部署
CI/CD Catalog 是一个项目列表，其中包含已发布的 CI/CD 组件，你可以使用这些组件来扩展你的 CI/CD 工作流。
任何人都可以 创建组件项目 并将其添加到 CI/CD Catalog 中，或者为现有项目做出贡献以改进可用组件。
如需点击演示，请参阅 CI/CD Catalog beta 产品导览。
查看 CI/CD Catalog
要访问 CI/CD Catalog 并查看可供你使用的已发布组件：
- 在顶部栏中，选择 搜索或跳转到。
- 选择 探索。
- 选择 CI/CD Catalog。
或者，如果你已经在项目的 流水线编辑器 中，可以选择 CI/CD Catalog。
CI/CD catalog 中组件的可见性遵循组件源项目的 可见性设置。源项目设置为以下内容的组件：
- 私有：仅对源组件项目中分配了访客、计划者、报告者、开发者、维护者或所有者角色的用户可见。要使用组件，你必须具有报告者、开发者、维护者或所有者角色。
- 内部：仅对登录到 极狐GitLab 实例的用户可见。
- 公开：对有权访问 极狐GitLab 实例的任何人可见。
查看 catalog 资源分析
Tier: 基础版，专业版，旗舰版
Offering: JihuLab.com，私有化部署
版本历史
- 在 极狐GitLab 18.9 中引入。
如果你维护 CI/CD catalog 资源，可以查看使用情况分析，以了解你的组件在不同项目中的采用情况。
先决条件：
- 你必须对一个或多个 catalog 资源项目具有维护者或所有者角色。
要查看 catalog 资源分析：
- 在顶部栏中，选择 搜索或跳转到 > 探索。
- 选择 CI/CD Catalog。
- 选择 分析 选项卡。
分析视图显示你拥有维护者或所有者角色的 catalog 资源。 此视图显示：
- 项目：catalog 资源名称及其最新发布版本。
- 使用统计：在过去 30 天内在流水线中使用过此 catalog 资源中某个组件的唯一项目数。
- 组件：catalog 资源最新版本中可用的组件列表。
例如：
你可以使用此信息来：
- 确定哪些 catalog 资源被最广泛采用。
- 跟踪组件随时间的使用趋势。
- 了解哪些项目正在使用你的 catalog 资源。
- 就组件维护和弃用做出明智的决策。
发布组件项目
要在 CI/CD catalog 中发布组件项目，你必须：
- 将项目设置为 catalog 项目。
- 发布新版本。
将组件项目设置为 catalog 项目
要使组件项目的已发布版本在 CI/CD catalog 中可见，你必须将项目设置为 catalog 项目。
先决条件：
- 你必须对项目具有所有者角色。
要将项目设置为 catalog 项目：
- 在顶部栏中，选择 搜索或跳转到 并找到你的项目。
- 在左侧边栏中，选择 设置 > 通用。
- 展开 可见性、项目功能、权限。
- 打开 CI/CD Catalog 项目 切换开关。
只有在发布新版本后，项目才会在 catalog 中可被发现。
要使用自动化启用此设置，你可以使用 mutationcatalogresourcescreate GraphQL 端点。议题 463043 提议也在 REST API 中公开此功能。
发布新版本
CI/CD 组件可以在未在 CI/CD catalog 中列出的情况下 使用。但是，在 catalog 中发布组件的版本使其可被其他用户发现。
先决条件：
- 你必须对项目具有维护者或所有者角色。
- 项目必须：
- 被设置为 catalog 项目。
- 已定义 项目描述。
- 在要发布的标签的提交 SHA 的根目录中有一个 README.md 文件。
- 在要发布的标签的提交 SHA 的 templates/ 目录中至少有一个 CI/CD 组件。
- 你必须使用 CI/CD 作业中的 release 关键字 来创建版本，而不是使用 Releases API。
要将组件的新版本发布到 catalog：
-
在项目的 .gitlab-ci.yml 文件中添加一个作业，该作业使用 release 关键字在创建标签时创建新版本。你应该配置标签流水线，在运行发布作业之前 测试组件。例如：
yaml1create-release: 2 stage: release 3 image: registry.gitlab.com/gitlab-org/cli:latest 4 script: echo "创建 release $CI_COMMIT_TAG" 5 rules: 6 - if: $CI_COMMIT_TAG 7 release: 8 tag_name: $CI_COMMIT_TAG 9 description: "发布 $CI_PROJECT_PATH 中组件的 $CI_COMMIT_TAG"
发布作业成功完成后，版本即被创建，新版本将发布到 CI/CD catalog。
语义化版本控制
版本历史
- 在 极狐GitLab 16.10 中引入。
当为组件打标签并 发布新版本 到 Catalog 时，你必须使用 语义化版本控制。语义化版本控制是传达变更是主要、次要、补丁或其他类型变更的标准。
例如，1.0.0、2.3.4 和 1.0.0-alpha 都是有效的语义化版本。
取消发布组件项目
要从 catalog 中移除组件项目，请在项目设置中关闭 CI/CD Catalog 资源 切换开关。
要再次在 catalog 中发布组件项目，你需要 发布新版本。
已验证的组件创建者
版本历史
- 在 极狐GitLab 16.11 中为 JihuLab.com 引入。
- 在 极狐GitLab 18.1 中为私有化部署引入。
一些 CI/CD 组件带有图标标记，以表明该组件是由 极狐GitLab 或实例管理员验证的用户创建和维护的：
-
极狐GitLab 维护 (
)：由 极狐GitLab 创建和维护的 JihuLab.com 组件。 -
极狐GitLab 合作伙伴 (
)：由 极狐GitLab 验证的合作伙伴独立创建和维护的 JihuLab.com 组件。极狐GitLab 合作伙伴可以联系 极狐GitLab 合作伙伴联盟的成员，将其在 JihuLab.com 上的命名空间标记为 极狐GitLab 已验证。然后，位于该命名空间中的任何 CI/CD 组件都将被标记为 极狐GitLab 合作伙伴组件。合作伙伴联盟成员代表已验证的合作伙伴创建 内部请求议题（仅限 极狐GitLab 团队成员）。
极狐GitLab 合作伙伴创建的组件按原样 提供，不提供任何形式的担保。最终用户使用 极狐GitLab 合作伙伴创建的组件需自行承担风险，极狐GitLab 对最终用户使用该组件不承担任何赔偿义务或任何类型的责任。最终用户使用此类内容以及与之相关的任何责任应由内容发布者和最终用户之间解决。
-
已验证创建者 (
)：由管理员验证的用户创建和维护的组件。
将组件设置为由已验证创建者维护
Tier: 基础版，专业版，旗舰版
Offering: 私有化部署
版本历史
- 在 极狐GitLab 18.1 中为私有化部署引入。
极狐GitLab 管理员可以将 CI/CD 组件设置为由已验证创建者创建和维护：
-
使用管理员帐户在实例中打开 GraphiQL，例如：https://gitlab.example.com/-/graphql-explorer。
-
运行此查询，将 root-level-group 替换为要验证的组件的根命名空间：
graphql1mutation { 2 verifiedNamespaceCreate(input: { namespacePath: "root-level-group", 3 verificationLevel: VERIFIED_CREATOR_SELF_MANAGED 4 }) { 5 errors 6 } 7}
查询完成后，根命名空间中项目内的所有组件都将被验证。已验证创建者 徽章将显示在 CI/CD catalog 中的组件名称旁边。
要从组件中移除徽章，请使用 UNVERIFIED 作为 verificationLevel 重复查询。
将 CI/CD 模板转换为组件
你在项目中使用 include: 语法使用的任何现有 CI/CD 模板都可以转换为 CI/CD 组件：
- 决定是否希望该组件作为现有 组件项目 的一部分与其他组件组合在一起，或者 创建新的组件项目。
- 根据 目录结构 在组件项目中创建一个 YAML 文件。
- 将原始模板 YAML 文件的内容复制到新的组件 YAML 文件中。
- 重构新组件的配置以：
- 利用组件仓库中的 .gitlab-ci.yml 来 测试对组件的更改。
- 打标签并 发布组件。
你可以通过遵循 将 Go CI/CD 模板迁移到 CI/CD 组件 的实践示例来了解更多信息。
在私有化部署实例上使用 JihuLab.com 组件
Tier: 专业版，旗舰版
Offering: 私有化部署
全新安装的 极狐GitLab 实例的 CI/CD catalog 开始时没有已发布的 CI/CD 组件。要填充实例的 catalog，你可以：
- 发布你自己的组件。
- 在你的私有化部署实例中镜像来自 JihuLab.com 的组件。
要在你的私有化部署实例中镜像 JihuLab.com 组件：
- 确保允许对 jihulab.com 进行 网络出站请求。
- 创建一个群组 来托管组件项目（推荐群组：components）。
- 在新群组中 创建组件项目的镜像。
- 为组件项目镜像编写 项目描述，因为镜像仓库不会复制描述。
- 将自托管组件项目设置为 catalog 资源。
- 通过为标签（通常是最新标签）运行流水线 在自托管组件项目中发布 新版本。
CI/CD 组件安全最佳实践
对于组件用户
由于任何人都可以向 catalog 发布组件，因此在使用组件之前，你应该仔细审查组件。使用 极狐GitLab CI/CD 组件的风险由你自行承担，极狐GitLab 无法保证第三方组件的安全性。
在使用第三方 CI/CD 组件时，请考虑以下安全最佳实践：
- 审计和审查组件源代码：仔细检查代码以确保其不含恶意内容。
- 最小化对凭证和令牌的访问：
- 审计组件的源代码，以验证任何凭证或令牌仅用于执行你预期和授权的操作。
- 使用范围最小的访问令牌。
- 避免使用长期有效的访问令牌或凭证。
- 审计 CI/CD 组件使用的凭证和令牌。
- 使用固定版本：将 CI/CD 组件固定到特定的提交 SHA（首选）或发布版本标签，以确保流水线中使用的组件的完整性。仅在你信任组件维护者时才使用发布标签。避免使用 latest。
- 安全存储密钥：不要将密钥存储在 CI/CD 配置文件中。如果你可以使用外部密钥管理解决方案，请避免在项目设置中存储密钥和凭证。
- 使用临时的、隔离的 runner 环境：尽可能在临时的、隔离的环境中运行组件作业。注意自托管 runner 的 安全风险。
- 安全处理缓存和产物：除非绝对必要，否则不要将流水线中其他作业的缓存或产物传递给 CI/CD 组件作业。
- 限制 CI_JOB_TOKEN 访问：为使用 CI/CD 组件的项目限制 CI/CD 作业令牌 (CI_JOB_TOKEN) 项目访问和权限。
- 审查 CI/CD 组件更改：在更改使用组件的更新提交 SHA 或发布标签之前，仔细审查 CI/CD 组件配置的所有更改。
- 审计自定义容器镜像：仔细审查 CI/CD 组件使用的任何自定义容器镜像，以确保它们不含恶意内容。
对于组件维护者
为了维护安全且可信的 CI/CD 组件，并确保你交付给用户的流水线配置的完整性，请遵循以下最佳实践：