跳至主要内容

基础设施

本页概述 conda-forge 基础设施，即 conda-forge 贡献者维护的各个组成部分，以及共同构成 conda-forge 运行基础的第三方提供商。

首先介绍 conda-forge 自身维护的不同 Github 存储库，然后介绍这些存储库中可用的管理命令，即所谓的 管理 Web 服务，接着介绍 CI 服务，即用于构建和维护包的第三方提供商。然后，我们转向描述包构建环境的一些方面，包括 编译器和运行时，以及 关于上传到包服务器的详细信息。

然后，我们将看到包构建过程如何与基础设施的不同部分交互。

最后，我们简要 列出所涉及的实体。

存储库​

暂存配方​

此存储库是 conda-forge 的门户，用户可以提交新的配方，一旦经过审核并被接受，将生成新的 feedstock 和团队。您可以在 暂存过程 中找到提交新包配方的详细指南。

暂存配方的结构​

recipes/ 包含一个或多个包含用户提交的配方的子目录。大多数情况下，用户一次只提交一个配方，但如果存在多个子目录，build_all.py 脚本将按正确的顺序构建它们，以确保依赖项得到满足。

.ci_support 包含 conda-build YAML 配置文件，但在此情况下（与 feedstock 相比），您还会发现一些脚本

  • build_all.py：按正确的（拓扑排序）顺序调用 conda-build。
  • compute_build_graph.py：通过提供包含所有提交的配方的作业图来支持 build_all.py。

.ci_support 中包含的 YAML 文件是极简的，不会像你在 feedstock 中找到的那样渲染。相反，conda-build 会在运行时将这些文件与来自 conda-forge-pinning 的固定信息结合起来。还要注意，staged-recipes 仅构建 x64。仅在提供 feedstock 后才能支持其他体系结构。

  • Linux：linux64.yaml 以及 CUDA (10.2、11.0、11.1 和 11.2) 变体。
  • macOS：osx64.yaml。
  • Windows win64.yaml。

目录 .scripts 包含与 feedstock 中用于 CI 管道的 shell 脚本大致相同的脚本。但是，由于 staged-recipes 不支持重新渲染，因此这些脚本是手动保持同步的，通常会看到一些差异。

工作流​

staged-recipes 上运行的主要作业是 conda-build 作业，该作业在每个 PR（以及对 main 的推送）上运行，以检查配方是否正确构建包。这些作业在 .azure-pipelines/ 中定义的 Azure Pipelines 上运行。

feedstock 的实际创建是在 conda-forge/admin-requests 中运行的。

其他工作流帮助用户正确设置他们的配方。他们会对 PR 中的事件做出反应

外部服务也连接到 staged-recipes

  • @conda-forge-admin 机器人（部署在 webservices）将根据配方的内容在 PR 中进行 lint 并提供提示。

Feedstock​

  • ⚙️ 部署在 Github 存储库中
  • 🔒 具有 Azure Pipelines、Github Actions、Anaconda.org (cf-staging) 的访问权限
  • 🔐 可能通过 admin-requests 具有 Travis CI、Cirun 的访问权限（WIP）
  • 🤖 与 admin-migrations、admin-requests、autotick-bot 和 webservices 集成。

Conda-forge 拥有数千个 feedstock。每个 feedstock 都包含一个配方以及所需的管道、支持脚本和配置元数据。

feedstock 的内容有明确的规定。只有两个位置是用户管理的

  • recipe/：包含构建包的 conda-build 指令。它至少需要一个 meta.yaml 文件，通常还会包含可选的 conda_build_config.yaml 文件。
  • conda-forge.yml：这是 feedstock 配置文件。
警告

您不应该手动编辑上面未列出的文件！更改将在下次 feedstock 重新渲染时被覆盖。

将这两个来源与一些外部组件结合起来，conda-smithy 将生成（渲染）feedstock 的内容。许多目录的命名方式是因为这是外部服务（例如 Azure）所要求的。但是，一些 conda-smithy 独有的目录值得讨论

  • .ci_support/：包含已渲染的 conda_build_config.yaml 文件，通过 -m 标志传递给 conda-build。这里每个文件都对应于 CI 构建矩阵中的一个作业。
  • .ci_support/migrations/：特殊的 YAML 文件，指示 conda-smithy 如何更新 .ci_support/*.yaml 文件。这些迁移文件通常由 autotick-bot 基础设施放在这里，并在迁移完成后移除。
  • .scripts/：支持您可以在 CI 管道和本地调试工具中找到的步骤的通用逻辑和代码。
  • build-locally.py：一个 Python 脚本，用于在您的机器上调试配方，与 CI 管道中的操作大致相同。
了解更多（WIP）
  • 重新渲染 feedstock
  • 推荐的工作流

feedstock 单一存储库​

一个包含所有 feedstock 作为子模块的单个存储库。

feedstock-outputs​

此存储库是 feedstock 名称及其生成的包（工件）的注册表。

它的主要目的是为验证服务器提供允许列表，以防止恶意跨 feedstock 构建，尽管它也是 feedstock <-> 包 的信息映射，在 网站的包部分 中公开。

cdt-builds​

此特殊存储库为 conda-forge 构建核心依赖树包（仅限 Linux）。它不使用 feedstock 自动化机制。相反，它有自己的 Azure Pipelines 工作流和一个有据可查的 README。

msys2-recipes​

这是 Anaconda 中旧的社区配方存储库的 fork，其中包含 msys2/ 目录下的 msys2配方。还要注意 common-scripts/ 文件夹中的支持脚本。

网站​

当前的 conda-forge.org 是一个静态生成的网站，发布到 Github Pages。

文档使用 Docusaurus 构建，源文件位于仓库的 docs/ 目录中。

如果您发现任何错别字、错误、不清楚的解释或可以涵盖的新主题，您可以建议对文档进行更改。有关更多详细信息，请参阅 改进文档。

除了静态文档之外，网站还提供有关 conda-forge 当前状态的信息以及包到 feedstock 的映射。

元数据仓库​

这些是主要存储 conda-forge 生态系统中其他部分使用的元数据的仓库。

conda-forge 固定​

托管 conda-forge 的全局固定以及正在进行的迁移。

包范围的依赖项固定在 conda_build_config.yaml 中定义，位于 conda-forge/conda-forge-pinning-feedstock。

有关 conda-forge 范围的包固定的更多信息，请参阅 全局固定的包。

如果您认为需要升级固定，请在那里打开一个 PR 和/或问题。有关更新全局固定的包的更多信息，请参阅 更新包固定。

conda-forge-repodata-patches​

该仓库创建 Anaconda.org 使用的 repodata.json 修补程序，以修改来自已发布包的元数据。

conda-forge-ci-setup​

此特殊的 feedstock 提供一个包，该包定义了跨提供程序安装和配置通用 CI 设置的逻辑。

regro/cf-graph-countyfair​

这是 autotick-bot 使用的图表数据。

构建图表的逻辑由 cf-scripts 提供。

docker-images​

该仓库构建用于在所有 Linux 构建中提供统一系统的 Docker 镜像。

代码仓库​

这些是存储程序和其他定义行为的代码的仓库。但是，它们的行动通常不是在这里触发的，而是由 conda-forge 生态系统中的其他部分使用的。

Smithy​

这是主要的 feedstock 创建和维护工具。

它的大部分用法都是由我们的基础设施自动化的

  • 在 staged-recipes 中创建 feedstock 和注册服务
  • 在 webservices 上，conda-forge-admin 在 PR 中进行重新生成（重新渲染）、代码检查和提示

但是，您也可以在本地或 forge 类部署中使用它。对于本地调试，您会发现以下命令很有用

  • conda-smithy rerender
  • conda-smithy recipe-lint

Smithy 包含 conda-forge 的维护代码，该代码由 conda-smithy 命令行工具和 管理 Web 服务 使用。

conda-forge/conda-smithy 是报告错误的正确仓库

  • 重新渲染过程
  • 配方代码检查器
  • CI 支持工具

conda-smithy 还包含命令行工具，如果您从命令行手动重新渲染，则应使用该工具（请参阅 重新渲染 feedstock）。

Smithy 可用于超出 conda-forge 目的以外的用途。例如，它可用于为非 conda-forge 基础设施设置自托管 Azure 代理。（您也可以考虑使用 Azure 虚拟机规模集代理，与永久活动代理相比，运行成本可能更低。）

Web 服务​

提供 conda-forge Web 服务的 Heroku 应用程序位于 conda-forge/conda-forge-webservices 中。请注意，应用程序提供的代码逻辑位于 Smithy 仓库中。

因此，有关服务功能的错误或建议应在 conda-forge/conda-smithy 的 错误跟踪器 中打开。

regro/cf-scripts​

autotick-bot 背后的代码和逻辑。

自动维护​

这些组件以自动化方式执行操作，这些操作要么由特定事件触发，要么作为循环的一部分持续进行。

admin-migrations​

该仓库托管 24/7 运行的工作流程。它的工作是提供一个自动化循环，其中添加了一些维护任务。它的主要用户是核心团队。

admin-requests​

该仓库托管主要在用户启动的操作触发时运行的工作流程。这通常通过一个 PR 完成，一旦获得批准，就会被合并并触发所请求的操作（将包标记为损坏，存档 feedstock 等）。

它还负责为已合并到 conda-forge/staged-recipes 的配方创建新的 feedstock。 create_feedstocks 工作流程 每小时运行几次，以在 conda-forge 组织上创建新的 feedstock 仓库。核心逻辑在 Python 脚本 .github/workflows/scripts/create_feedstocks.py 中定义。

autotick-bot​

注意

旧仓库 regro/autotick-bot 现在已不再使用；该机器人现在直接在 regro/cf-scripts 中运行。

webservices​

此 Web 应用程序为多种服务提供支持，例如

  • @conda-forge-admin 机器人和其 @conda-forge-admin, please ... 命令
  • cf-staging 到 conda-forge 的验证（以及复制）
  • 状态监控

管理 Web 服务​

conda-forge 在 Heroku 上运行一个名为 conda-forge-webservices 的 Web 服务。

以下服务在默认情况下在原料库中运行

  • 它将对 PR 中的食谱进行 linting 并报告食谱是否处于良好状态。
  • 当维护人员被添加到食谱中时，每个维护人员都将被添加到团队中，并获得原料库的推送权限。

Web 服务还会监听问题和 PR 评论，以便您可以要求完成以下服务

@conda-forge-admin，请重新渲染​

在原料库的 PR 中输入上述短语将重新渲染原料库并将更改推送到您的 PR。请确保选中 PR 右侧边栏底部“允许维护人员编辑”按钮。如果您在问题的评论中输入此短语，该机器人将创建一个新的拉取请求，并完成请求的重新渲染。

@conda-forge-admin，请添加 noarch: python​

在原料库的 PR 或问题中输入上述短语将在您的构建中添加 noarch: python 并为您重新渲染原料库。

@conda-forge-admin，请执行 linting​

在原料库的 PR 中输入上述短语将再次执行 PR 的 linting。

@conda-forge-admin，请更新团队​

在问题中输入上述短语将更新原料库的团队。这通常是自动完成的。

@conda-forge-admin，请重启 CI​

在原料库或暂存食谱的 PR 中输入此命令将关闭并重新打开 PR，导致所有 CI 构建重新启动。

@conda-forge-admin，请ping团队​

在原料库或暂存食谱的 PR 中输入此命令将使管理员机器人@提及与仓库关联的团队。此命令对尚未成为 conda-forge 成员的人员非常有用，因此他们无法@提及 staged-recipes 团队进行 PR 审查。

@conda-forge-admin，请pingconda-forge/​

在原料库或暂存食谱的 PR 中输入此命令将使管理员机器人@提及相应的团队。此命令对尚未成为 conda-forge 成员的人员非常有用，因此他们无法@提及某人，因为存在一般的 GitHub 限制。

@conda-forge-admin，请重新运行机器人​

在 PR 评论中输入此命令将在该 PR 中添加 bot-rerun 标签。此标签将导致发出迁移和版本更新的 auto-tick 机器人关闭当前 PR 并重新发布它。在非机器人发出的 PR 中添加此标签将不起作用。

@conda-forge-admin，请添加机器人自动合并​

在问题的标题或评论中输入此命令将指示管理员机器人打开一个 PR，以启用来自 auto-tick 机器人的通过 PR 的自动合并。此功能目前处于实验阶段。您可以找到更多详细信息 here。对于任何反馈、错误和/或问题，请在 regro/cf-scripts 上打开问题！

@conda-forge-admin，请删除机器人自动合并​

在问题的标题或评论中输入此命令将指示管理员机器人打开一个 PR 来禁用自动合并，撤消 请添加机器人自动合并 命令。

@conda-forge-admin，请添加用户 @username​

在原料库的 issue 的标题中输入上述短语将创建一个 PR，该 PR 将给定用户添加到原料库中。维护人员或 core 的成员可以合并此 PR 以添加用户。请不要修改此 PR 或调整提交消息。此 PR 旨在跳过包的构建。

@conda-forge-admin，请更新版本​

在原料库的 issue 的标题中输入上述短语将请求机器人检查是否有任何新版本可用。如果有，它将打开一个带有必要更改的 PR。请注意，机器人可能会先打开一个 PR，其中只有部分更改。其余内容将在几分钟后在后续提交中添加。

CI 构建服务​

在这里，我们描述了 conda-forge 构建的 CI 服务的常见问题。

Azure 管道​

Azure 用于为 Windows（原生 x86_64）、macOS（原生 x86_64）、Linux（原生 x86_64、模拟 ARMv8 和 IBM Power8+）构建包。Azure 上的构建队列比所有其他提供商的构建队列都要大。Azure 构建的最大持续时间为 6 小时。

要查看 Azure 上的所有构建，请访问 https://dev.azure.com/conda-forge/feedstock-builds/_build.

重启构建​

目前 Azure 不会同步 GitHub 用户。为了重启构建，您可以从 GitHub 检查界面重启它。如果这不起作用，关闭/打开将启动一个新的构建。您也可以使用 Web 服务命令 @conda-forge-admin，请重启 CI。

TravisCI（IBM Power 8+、ARM）​

TravisCI 用于为 IBM Power 8+ 和 ARM 构建包。合并暂存食谱的拉取请求后，可能需要强制同步 TravisCI 中的存储库以查看重新加载和取消按钮。为此，请访问 https://app.travis-ci.com/account/repositories 并单击“同步帐户”按钮。

启用 Travis​

TravisCI 应该只用于在原生 Linux aarch64 和 ppc64le 上构建食谱。

通过将以下内容中的相应行添加到食谱根目录中的 conda-forge.yml 来启用构建。

provider:
  osx: travis
  linux_ppc64le: travis
  linux_aarch64: travis

对于 IBM Power 8+ 和/或 ARM 构建，请通过拉取请求将您的食谱名称添加到列表中 here。

GitHub Actions​

我们使用 GitHub Actions 来重新渲染食谱，也运行我们的拉取请求自动合并服务。我们目前不支持在 GitHub Actions 上构建。

自动合并​

自动合并服务使用此 repo 中的 GitHub Actions。此 Actions 从 prod 标签上的 Docker container 中运行。有关更多详细信息，请参阅此存储库的 README.md。如果 PR 满足以下两个条件集中的任何一个，则会自动合并

  1. 来自 regro-cf-autotick-bot，标题中包含 [bot-automerge]，所有状态都已通过，并且原料库允许自动合并
  2. 具有 automerge 标签，并且所有状态都已通过。

对于来自 regro-cf-autotick-bot 的 PR，如果您对 PR 进行编辑，删除 PR 标题中的 [bot-automerge] 标记可能很有用。

重新渲染​

重新渲染服务由 Heroku 应用程序触发。它使用此 repo 中的 GitHub Actions。此 Actions 从 prod 标签上的 Docker container 中运行。有关更多详细信息，请参阅此存储库的 README.md。

跳过 CI 构建​

要跳过给定提交的 CI 构建，请在提交消息中添加 [ci skip] ***NO_CI***。

相关链接

第三方使用我们的 CI 服务​

由于 conda-forge 在开源社区中的地位，它增强了对某些 CI 服务的访问权限。此访问权限是社区资源，委托给 conda-forge 用于构建软件包。因此，我们无法在我们的任何 CI 服务上的 feedstock 中支持第三方或“非标” CI 任务。如果我们发现此类使用，我们将礼貌地要求维护者纠正情况。如果情况无法得到纠正，我们可能会采取更严厉的措施，包括存档 feedstock 或从组织中移除维护者。

编译器和运行时​

conda-forge 构建并维护其自身的一套编译器，用于各种语言和/或系统（例如，C、FORTRAN、C++、CUDA 等）。这些编译器用于我们所有的 CI 构建中，以构建 conda-forge 发布的几乎所有工件。

除了构建所有内容之外，此编译器基础设施还发挥着至关重要的作用，即确保软件包彼此兼容。这是由于编译后的软件包具有所谓的 应用程序二进制接口 (ABI)，以及编译器基础设施的更改可能会破坏此 ABI，从而导致崩溃、错误计算等。一般来说，使用一致的编译器版本可以大大降低 ABI 崩溃的风险。

编译器通常努力在版本之间保持 ABI 兼容性，这意味着由不同版本的同一编译器为同一目标生成的工件的组合将一起工作，而不会出现问题。由于 ABI 的性质（即软件和硬件之间庞大的接口，具有无数的边缘情况），仍然会发生在编译器版本之间引入对某些特定方面的无意更改，尽管在实践中这不会导致广泛的问题。

相反，当编译器有意更改 ABI 时（例如，MSVC 在当前涵盖 VS2015-VS2022 的 vc14 系列之前每次发布都会这样做），每个编译后的软件包都需要为该新 ABI 重新构建，并且不能与旧 ABI 的构建混合使用。虽然现在不太可能，但原则上也可能编译器堆栈中的重大基础设施大修类似地迫使完全重建。

这种大规模的更改——需要重建 +/- 所有 conda-forge——需要付出很多努力，但值得庆幸的是，近年来，这种完全重建并不必要，我们设法进行了破坏性较小的编译器升级。

然而，大规模的 ABI 崩溃仍然有可能（例如，MSVC 正在计划在 vc14 之后发布 vNext），因此我们保留了针对这种情况的策略。虽然我们没有对一代 ABI 兼容的编译器提供任何正式的支持承诺，但从历史上看，我们根据以下（非约束性）原则维护了它们。

  • 各种语言和平台的当前编译器和版本的权威来源是 conda_build_config.yaml，位于 conda-forge/conda-forge-pinning-feedstock 中，如 全局固定软件包 中所述。
  • 对于给定编译器一代的长期稳定性/支持，我们不提供任何形式的支持。
  • 我们以一种临时的方式在定期基础上升级它们，因为我们有时间和精力这样做。请注意，由于我们强制执行运行时约束的方式，这些编译器升级不会破坏现有软件包。但是，如果您在 conda 之外使用这些编译器，那么您可能会遇到问题。
  • 当 ABI 不兼容的编译器更改即将发生时，我们通常会以公告的形式提供通知。请注意，这些更改需要一些时间才能完成，因此如果您需要，您通常会有时间准备。
  • 我们在考虑编译器迁移时会考虑的一些标准包括
    • 对生态系统的破坏程度，
    • core 团队的工作量，
    • 这对我们的（志愿者）feedstock 维护者来说需要多长时间。

这些编译器一代可能有一些非官方名称供我们内部使用（例如 comp7）。我们再次注意到，这些名称的存在并不意味着对构成给定堆栈的编译器的任何级别的支持或稳定性。

对于不需要完全重建 conda-forge 的情况（即，如果新编译器的 ABI 保持兼容，直到罕见的边缘情况），我们只需在全局固定中增加版本，它将随着 feedstock 被重新渲染而缓慢地推广到生态系统中。

对于这种 ABI 兼容的升级，类似但更松散的原则适用

  • 这些固定在全局固定中也有类似的定义，请参阅 全局固定软件包。
  • 对于给定编译器版本的长期可用性，我们不提供任何形式的支持。
  • 当编译器即将升级时，我们通常会以公告的形式提供通知。
  • 没有承诺任何时间表，我们在 Linux 和 OSX 上的编译器通常是最新的；在 Windows 上，我们通常使用最后一个受支持的 VS 版本。

尽管缺乏明确的支持，但我们仍然试图使各个版本的编译器在 conda-forge 之外也能正常工作，甚至提供了一种简单的方法来安装它们（通过 compilers feedstock）。

更具体地说，每个编译器都使用一个激活软件包，它区分了它仅仅存在于构建环境中，以及它被默认使用。当在 meta.yaml 中使用 {{ compiler('xyz') }} 时，这些软件包将被安装，其中 'xyz' 是 'c'、'cxx'、'fortran'、'cuda'、'rust'、'go-cgo'、'go-nocgo' 之一。

我们的默认编译器堆栈在每个平台上的构成截然不同；每个平台都有自己的默认编译器，以及提供这些编译器的自己的一组 feedstock。由于历史原因（编译器与其操作系统的集成方式，以及用它们编写的软件数量等），最具影响力的语言是 C & C++（尽管 Fortran 被认为是默认的一部分，主要是因为 GCC 编译了所有三种语言）。

Linux (GCC)

OSX (Clang)

Windows (MSVC)

在 Windows 上存在一个基于 MinGW 的替代编译器堆栈，该堆栈可以使用 m2w64_ 前缀获得（例如 {{ compiler('m2w64_c') }}）。但是，现在大多数项目都将原生支持用 MSVC 进行编译，此外还有混合编译器堆栈导致的几个复杂问题，因此它正在逐渐被弃用。

此外，可以使用 clang 作为 Linux 和 Windows 上的编译器

除了主要的 C/C++/Fortran 编译器之外，这些是其他编译器的 feedstock

要升级 Linux 或 OSX 上全局固定中默认编译器的编译器版本，请确保上述相应的 feedstock 已为新主版本重建，所有相关的版本同时提升，并且编译器显然正常工作（例如，通过在某些 feedstock 上测试它们，通过 feedstock 本地的 conda_build_config.yaml 指定新版本）。您还应该检查编译器发行说明以了解有关 ABI 不兼容性的警告，并在有关升级的讨论中提及任何此类通知。

对于 Windows，我们会更长时间地停留在较旧的编译器上，因为使用更新的工具链会迫使所有希望使用 conda-forge 工件进行本地开发的人使用至少与之一样新的工具链。您可以在此 关于更新到 vc142 工具链的问题 中找到有关此主题的更多详细信息。

用于 linux-* 平台的 CentOS sysroot​

我们目前重新打包来自 CentOS 适当版本的 sysroot，以供我们的编译器使用。这些 sysroot 文件可在 sysroot_linux-* 软件包中找到。这些软件包的版本号与其打包的 glibc 版本匹配。这些版本对于 CentOS 6 为 2.12，对于 CentOS 7 为 2.17。

对于 ppc64le 上 8.4.0 之前的 gcc/gxx/gfortran 版本，以及 aarch64/x86_64 上 7.5.0 之前的版本，我们一直在构建我们自己的 glibc 版本。这种做法现在已过时，我们建议使用基于 CentOS 的 sysroots。此外，从上述相同的编译器版本开始，我们删除了 sysroot 路径中的 cos* 部分。新的 sysroot 路径中只有 conda，而不是 conda_cos6 或 conda_cos7。

输出验证和 feedstock 令牌​

截至撰写本文时，anaconda.org 不支持生成仅允许上传某些软件包而不允许上传其他软件包的 API 令牌。为了保护软件包源上传的安全，例如，防止 numpy 软件包源的维护者推送 python 软件包，我们使用软件包暂存流程并发布特定于每个软件包源的秘密令牌。此流程的工作原理如下。

  1. 当软件包源上的 CI 作业构建要上传到 anaconda.org 的软件包时，它首先将这些软件包上传到暂存频道 cf-staging。
  2. 然后，软件包源 CI 作业使用其秘密令牌向我们的管理员 Web 服务服务器发出 API 调用，并提供有关其尝试上传的软件包的一些信息。
  3. Web 服务服务器验证秘密令牌、软件包的完整性以及软件包是否允许用于给定的软件包源。
  4. 如果所有验证都通过，则软件包将被复制到 conda-forge 频道。

我们尝试通过在软件包源中的提交/问题上的评论向用户报告此过程中的错误。但是请注意，有时这些评论会失败。如果您认为您的上传遇到了问题，请确保在您的 conda-forge.yml 中设置了 conda_forge_output_validation: true，并使用最新版本的 conda-smithy 重新渲染您的软件包源。最后，添加到软件包源的新软件包会自动注册，并且在成功上传后，其他任何软件包源都无法上传具有相同名称的软件包。

但是，有时可能更合理地从不同的软件包源生成软件包，例如，由于软件包重命名或重构。在这种情况下，您可能需要将新的软件包源添加到 feedstock-outputs 映射中。如果未执行此操作，则输出验证流程将阻止从新的软件包源上传软件包，这是设计使然。一旦正确完成此操作并上传了软件包，您就可以请求 conda-forge 核心开发人员存档旧的软件包源。

软件包构建阶段和相关的基础设施​

conda-forge 中的软件包几乎1 总是通过 CI 构建。但是，当新的软件包第一次进入 conda-forge 时，它是通过 staged-recipes 存储库 中的拉取请求完成的，而此后每次新的软件包构建都是在相应的存储库（即所谓的软件包源）中构建的。这两个地方使用略微不同的 CI 设置，并相应地与基础设施进行交互。因此，我们首先描述新软件包开始时的交互，然后描述其各自软件包源中现有软件包的交互。

初始提交到 staged-recipes​

conda-forge/staged-recipes 存储库使用几部分基础设施。

在拉取请求上

  • 软件包构建管道。这些与软件包源中运行的管道略有不同（它们不是由 conda-smithy 自动生成的，但它们确实使用相同的基础组件）。
  • 代码检查由 conda-smithy recipe-lint 提供，由 @conda-forge-admin 运行。
  • 自动标签逻辑，由 Github Actions 工作流运行。

涉及的经过身份验证的服务

  • Github，具有以下权限
    • PR 标签
  • Azure Pipelines

staged-recipes 中的新配方的转换到其各自的软件包源是在由 admin-requests 运行的 cron 作业中完成的。有关更多详细信息，请参阅 admin-requests。作为软件包源创建的一部分，新的软件包源将收到一个与 webservices 连接的 Webhook。

软件包源更改​

软件包源可以出于多种原因收到更改。

推送至 main 或其他分支

  • 在 staged-recipes 中批准后，自动初始化提交。这些由 conda-smithy 生成，并由 admin-requests 中的自动化推送。
  • 从 admin-migrations 触发的自动维护提交。
  • 重新渲染请求由 conda-forge/webservices-dispatch-action 的实例处理，并由 webservices 触发。

自动拉取请求可以由以下人员打开...

  • @conda-forge-admin，响应某些标题类似于 @conda-forge-admin, please... 的问题。
  • @regro-cf-autotick-bot，处理迁移和新版本的可用性。

...并由以下人员关闭

  • conda-forge/automerge-action，如果相应地标记。

在打开的拉取请求上

  • 构建管道（更多内容 见下文）。
  • 代码检查由 conda-smithy recipe-lint 提供，由 @conda-forge-admin 运行。
  • @conda-forge-admin, please... 命令评论，由 @conda-forge-admin 回答。

在问题上

  • @conda-forge-admin, please... 命令问题，由 @conda-forge-admin 处理。

软件包构建​

构建 conda 软件包的管道用于 main 和其他分支中的拉取请求和推送事件。唯一的区别是，在拉取请求期间构建的软件包不会上传到暂存频道。维护这些管道在所有软件包源中保持最新需要多个存储库

  • conda-smithy 负责生成 CI 管道本身，以及支持脚本和配置文件。这些管道和脚本可以依赖于下面存储库中定义的代码和数据。
  • conda-forge-ci-setup-feedstock 提供在跨提供者准备和标准化 CI 运行器所需的代码。它还在将工件上传到 cf-staging 之前执行一些检查。
  • conda-forge-pinning-feedstock 定义了支持的多个运行时和库的版本，以及用于某些语言和平台的编译器。
  • docker-images 构建用于 Linux 运行器的标准化容器镜像。此存储库对 Docker Hub、Quay.io 具有额外的身份验证需求。

管道可以在 conda-smithy 支持的多个 CI 提供者上运行，包括

  • Azure DevOps Pipelines
  • Travis CI
  • Circle CI
  • Appveyor
  • 自托管的 Github Actions 运行器

钩子和触发器的注册也由 conda-smithy 应用程序完成。

提示

conda-smithy 支持更多 CI 提供者。有关更多详细信息，请查看 其存储库。

涉及的经过身份验证的服务

  • Anaconda.org 上传到 cf-staging

软件包验证和发布​

在 main（或其他分支）上构建后，conda 软件包会上传到名为 cf-staging 的中间频道。从那里，我们的 Web 服务（conda-forge/conda-forge-webservices）执行以下操作

  • 该逻辑检查软件包源令牌以验证合法的请求。
  • 该逻辑检查 cf-staging 上的软件包的哈希总和是否与 CI 中计算的值匹配，以确保要复制的工件相同。
  • 该逻辑检查软件包源是否允许使用 conda-forge/feedstock-outputs 存储库推送软件包。
  • 如果所有三个检查都通过，Web 服务会将工件从 cf-staging 复制到 conda-forge。

涉及的经过身份验证的服务

  • Anaconda.org 上传到 conda-forge 和 cf-staging
  • conda-forge-webservices 应用程序部署本身（目前在 Heroku 上）

发布后​

上传到 anaconda.org/conda-forge 后，软件包不会立即对 CLI 客户端可用。它们必须在内容分发网络 (CDN) 中复制。此步骤理想情况下应该需要大约 15 分钟。在某些情况下，可能会出现更长的延迟。如有疑问，请查看 conda-forge.org/status。

CDN 复制后，大多数在 anaconda.org/conda-forge 上可用的软件包不会再进行任何修改。但是，在某些情况下，维护人员可能需要对已发布的软件包执行某些操作

  • 修补其 repodata
  • 将它们标记为已损坏

Repodata 修补​

conda 软件包的元数据最初包含在每个软件包存档中（在 info/ 下）。conda index 会遍历已发布的 conda 软件包，提取元数据并将所有找到的 JSON 块合并到单个 JSON 文件中：repodata.json。这是添加哈希和文件大小的地方。这是 CLI 客户端最初下载以解决环境的元数据文件。

由于元数据位于软件包文件之外，因此可以修改某些详细信息而无需重新构建软件包，这简化了一些维护任务，尤其是。

Repodata 修补是在 conda-forge/conda-forge-repodata-patches-feedstock 中创建的，它最终生成（并上传）一个普通的 conda 软件包：conda-forge-repodata-patches。这些带时间戳的软件包中的每一个都包含 conda-forge 上每个频道子目录的修补指令。Anaconda 基础设施从这些软件包中获取 JSON 文件并将它们应用到原始 repodata.json 之上（原始 repodata.json 仍可作为 repodata_from_packages.json 下载）。

由于 conda-forge-repodata-patches-feedstock 作为常规的软件包源进行软件包发布，因此没有其他基础设施详细信息需要介绍。

将软件包标记为已损坏​

有时软件包存在 repodata 修补程序无法修复的错误（例如，二进制文件错误）。在这种情况下，conda-forge 不会从 Anaconda.org 中删除软件包。相反，它会用 broken 标签标记它们，该标签具有特殊的含义：标记为已损坏的软件包将通过自动修补程序从 repodata 中删除。此操作是可逆的，不会更改工件的直接 URL，该 URL 始终可以通过例如锁定文件下载。

处理此操作的主要存储库是 conda-forge/admin-requests，它具有每 15 分钟运行一次的不同 Github Actions 工作流。

对于此任务，Github Action 工作流需要访问

  • Anaconda.org，用于添加（或删除）标签
  • Github，用于在成功后修改和提交输入文件

服务和提供者清单​

Github 资源​

除了数千个存储库之外，conda-forge 还使用其他几种 Github 服务。

组织​

info

这些组织存在，但不再处于活跃使用状态

团队​

conda-forge Github 组织拥有数千个团队。 其中大多数与 feedstock 相关联，但也有少数几个特殊团队！

配置​

机器人账户​

info

这些帐户存在，但不再处于活跃使用状态

应用程序​

  • conda-forge-curator
  • conda-forge-webservices
info

这些应用程序存在，但不再处于活跃使用状态

  • conda-forge drone 实例

工作流程​

持续集成​

另请参阅

参考 conda-forge.yml 文档 以了解如何配置您的 CI 提供程序。

Azure Pipelines​

conda-forge 从慷慨提供的 Microsoft 托管的运行器中获益。

Travis CI​

Cirun​

  • 🌐 https://cirun.io
  • 📍 仅在选定的 feedstock 上可用
  • 🛠 提供多种架构 (取决于 feedstock 配置)
  • 🔒 需要访问 Anaconda.org (cf-staging) 和已配置的后端

使用 @conda-forge-daemon 配置。

组织范围内的配置可以在 .cirun 存储库 中找到。

info

例如，这允许访问针对选定 feedstock 的 GPU 支持的运行器，如 https://github.com/Quansight/open-gpu-server 中所述。

GitHub Actions​

已退役的服务​

交付和分发​

Anaconda.org​

Docker Hub​

GitHub Packages​

GitHub Releases​

Quay​

服务器​

Heroku​

其他服务​

脚注​

  1. 由于特殊的资源要求，很少有软件包无法通过 CI 构建。 这些软件包可以手动构建并上传，遵循 CFEP-3 中规定的规则。 ↩