LLVM CI 最佳实践

概述

本文档包含在使用 LLVM 的 CI 系统时使用的一系列指南和最佳实践。 这些指南旨在确保我们的操作可靠、一致和安全。

Github Actions 最佳实践

本节包含在使用 LLVM 的 github actions 工作流程时的最佳实践/指南信息。

在 Fork 中禁用作业

存在许多 LLVM fork，我们目前默认阻止操作在 LLVM 组织外部运行，以防止它们在 fork 中运行。 我们默认为此设置，因为通常不希望操作在 fork 中运行，而只是意外运行。 此外，我们的许多工作流程都假定它们在主 LLVM 仓库中运行，否则会中断。

遵循此最佳实践看起来像是在工作流程中指定的每个作业中添加以下内容

jobs:
  <job name>:
    if: github.repository_owner == 'llvm'

我们选择使用 github.repository_owner 而不是 github.repository 以便这些工作流程可以在 LLVM 组织内的 fork 中运行，例如 ClangIR fork。

此规则也有一些例外，在这些例外情况下，当限制工作流程仅在主 monorepo 仓库中运行时有意义时，可以使用 github.repository。 这些包括问题订阅者和发布任务等，这些任务不应在其他任何地方运行。

哈希固定依赖

Github Actions 允许使用来自其他仓库的操作作为作业中的步骤。 我们利用各种操作来执行各种不同的任务，特别是像检出仓库以及下载/上传构建缓存之类的任务。 这些操作通常仅使用版本进行版本控制，如下所示

steps:
  - name: Checkout LLVM
    uses: actions/checkout@v4

但是，最佳实践是指定要从中拉取操作的确切提交 SHA，并在注释中注明版本

一旦 Github 的不可变操作作为 GA 推出，我们计划重新审视此建议。

steps:
  - name: Checkout LLVM
    uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

这对于两个原因有利：可靠性和安全性。 指定确切的 SHA 而不仅仅是主版本可确保我们最终运行最初在工作流程被创作和/或更新时指定的相同操作，并且不会因新版本的工作流程发布而潜入任何重大更改。 但是，通过指定确切的点发布也可以实现此效果。 更喜欢哈希固定依赖的最大原因是安全性。 Github 上的发布资产是可变的，允许攻击者在事后更改特定版本操作中的代码，从而可能窃取敏感令牌和凭据。 哈希固定依赖可以防止这种情况，因为哈希会随代码而改变。

使用版本化的 Runner 镜像

Github actions 允许使用特定版本化的 runner 镜像（例如，ubuntu-22.04），或者仅使用最新的 runner 镜像（例如，ubuntu-latest）。 最佳实践是使用显式版本化的 runner 镜像。 这可以防止当 Github 将最新的 runner 镜像滚动到具有潜在重大更改的新版本时发生中断，而是允许我们在完成足够的测试以确保我们现有的工作流程在新环境中按预期工作后，显式选择加入使用新镜像。