跳到主要内容

基础设施

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

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

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

最后，我们将简要列出相关实体。

存储库​

Staged-recipes​

此存储库是 conda-forge 的入口，用户可以在其中提交新的配方，这些配方在经过审查和接受后，将生成新的 feedstock 和团队。您可以在暂存过程中找到提交新软件包配方的详细指南。

staged-recipes 的结构​

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

.ci_support 包含 conda-build YAML 配置文件，但在这种情况下（与 feedstocks 相比），您还会找到一些脚本

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

.ci_support 中包含的 YAML 文件是最小化的，并且不像您在 feedstocks 中找到的文件那样呈现。相反，conda-build 将采用这些文件，并在运行时将它们与来自 conda-forge-pinning 的 pinnings 结合起来。另请注意，staged-recipes 仅为 x64 构建。只有在提供 feedstock 后才能支持其他架构。

  • Linux：linux64.yaml 加上 CUDA 变体。
  • 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 中的事件做出反应

  • automate-review-labels：更新 PR 标签以简化审查和帮助请求。
  • linter：通用配方 linting 加上一些 staged-recipes 特定的检查，例如不编辑示例。

外部服务也连接到 staged-recipes

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

Feedstocks​

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

Conda-forge 有数千个 feedstocks。每个 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
  • 推荐工作流程

feedstocks monorepo​

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

feedstock-outputs​

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

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

cdt-builds​

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

msys2-recipes​

这是 Anaconda 上旧社区配方存储库的一个分支，其中包括 msys2/ 目录下的 msys2 配方。另请注意 common-scripts/ 文件夹中的支持脚本。

网站​

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

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

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

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

元数据存储库​

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

conda-forge pinning​

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

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

有关 conda-forge 范围的软件包 pins 的更多信息，请参阅全局 pinned 软件包。

如果您认为需要推进 pin，请在此处打开一个 PR 和/或 issue。有关更新全局 pinned 软件包的更多信息，请参阅更新软件包 pins。

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 创建和维护工具。

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

  • Feedstock 创建和服务注册在 staged-recipes
  • conda-forge-admin 在 webservices 上完成的再生（重新渲染）、linting 和 PR 中的提示

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

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

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

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

  • 重新渲染过程
  • 配方 linter
  • CI 支持实用程序

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

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

Web 服务​

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

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

regro/cf-scripts​

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

自动化维护​

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

admin-migrations​

此存储库托管 24/7 运行的工作流。其工作是获取一个自动化循环，在其中添加一些维护任务。其主要用户是核心团队。

admin-requests​

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

它还负责为已合并到 conda-forge/staged-recipes 中的配方创建新的 feedstocks。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 服务。

以下服务默认在 feedstock 上运行

  • 它将 lint PR 中的配方，并报告配方是否处于良好状态。
  • 当维护者被添加到配方时，每个维护者都将被添加到团队，并被授予对 feedstock 的推送访问权限。

Web 服务还监听 issue 和 PR 评论，因此您可以要求完成以下服务

@conda-forge-admin, please rerender​

在 feedstock 的 PR 中输入上述短语将重新渲染 feedstock 并将更改推送到您的 PR。确保勾选位于 PR 右侧边栏底部的允许维护者编辑按钮。如果您在 issue 的评论中输入此短语，机器人将创建一个新的 pull request，其中已完成请求的重新渲染。

@conda-forge-admin, please add noarch: python​

在 feedstock 的 PR 或 issue 中输入上述短语会将 noarch: python 添加到构建中，并为您重新渲染 feedstock。

@conda-forge-admin, please lint​

在 feedstock 的 PR 中输入上述短语将再次 lint PR。

@conda-forge-admin, please update team​

在 issue 中输入上述短语将更新 feedstock 的团队。这通常是自动完成的。

@conda-forge-admin, please restart ci​

在 feedstock 或 staged-recipes 的 PR 中输入此命令将关闭然后打开 PR，从而导致所有 CI 构建重新启动。

@conda-forge-admin, please ping team​

在 feedstock 或 staged-recipes 的 PR 中输入此命令将使管理员机器人 @-mention 与存储库关联的团队。此命令对于尚不是 conda-forge 成员的人员很有用，因此无法 @-mention staged-recipes 团队进行 PR 审查。

@conda-forge-admin, please ping conda-forge/​

在 feedstock 或 staged-recipes 的 PR 中输入此命令将使管理员机器人 @-mention 相应的团队。此命令对于尚不是 conda-forge 成员的人员很有用，因此由于 GitHub 的一般限制而无法 @-mention 某人。

@conda-forge-admin, please rerun bot​

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

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

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

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

在 issue 的标题或评论中输入此命令将指示管理机器人打开一个 PR 以禁用自动合并，撤消 please add bot automerge 命令。

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

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

使用此命令

这不是开始帮助 feedstock 的推荐方式。如果您有兴趣帮助处理特定的 recipe，最好从提交包含新版本或修复的 PR 开始。这样，您可以获得对您工作的反馈，并了解 feedstock 的一些历史背景。

一旦您与维护者建立了工作关系，您可以要求他们将您添加到 feedstock 团队。然后他们可以使用此命令将您添加到团队。对于如何添加新的维护者，没有任何官方要求，因此可能需要一段时间才能就何时添加新的维护者达成共识。不要因此而灰心丧气，停止贡献！

欢迎任何人打开 PR！！！感谢您的时间和努力！！！

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

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

CI 构建服务​

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

Azure Pipelines​

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, please restart ci。

TravisCI (IBM Power 8+, ARM)​

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

启用 Travis​

TravisCI 仅在原生 Linux aarch64 和 ppc64le 上构建 recipe 时才需要。

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

provider:
  osx: travis
  linux_ppc64le: travis
  linux_aarch64: travis

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

GitHub Actions​

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

Web 服务后台作业​

Web 服务 Heroku 应用程序调度到 GitHub Actions 以运行计算密集型后台作业，包括重新渲染、版本更新和自动合并作业。GitHub actions 运行发生在 conda-forge-webservices 仓库上。这些运行使用 webservices-dispatch-action Docker 容器进行某些操作。此容器已标记为最新的 Web 服务版本。

自动合并​

我们的自动合并服务通过 GitHub Actions 在 conda-forge-webservices 仓库中运行。

如果 PR 满足以下两组条件中的任何一组，则会自动合并 PR

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

对于来自 regro-cf-autotick-bot 的 PR，如果您要对 PR 进行编辑，则从 PR 标题中删除 [bot-automerge] slug 会很有用。

跳过 CI 构建​

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

相关链接

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

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

外部 Runner（用于 GitHub Actions）​

当当前的基础设施无法满足 feedstock 维护者的 CI 需求时，conda-forge 为他们提供了一种通过 Cirun 贡献/赞助外部 runner 的方式。这些外部 runner（即专用 runner）可用于在一个或多个 feedstock 上构建软件包，具体取决于维护者。它们是特定云或一组云上的 runner，即，促进外部 runner 的配置基本上是承诺赞助在 受支持的云上配置临时虚拟机。下面描述了该过程

  • 与 conda-forge/core 联系以讨论您的用例。这可以通过在相关的 feedstock 中提出 issue 或通过 Zulip 完成。
  • 讨论完毕后，与 conda-forge/core 成员共享受支持云的凭据，以便可以将其添加到 conda-forge 的 Cirun 帐户中，或者用户可以为现有的 conda-forge 云帐户赞助云积分。
  • 在 conda-forge/.cirun 中添加 runner 虚拟机的配置，并在 .access.yml 中添加策略条目，以允许 feedstock 访问 runner。
  • 在您的 <package-feedstock>/recipe/conda_build_config.yaml 的 github_actions_labels 下添加上面定义的标签，并重新渲染 feedstock。有关一些示例，请参见下面的链接。

完成上述步骤后，feedstock 维护者应该能够将定义的 runner 用于 feedstock 仓库的 CI 作业。

外部 runner 使用示例​

Pytorch 目前使用通过 cirun 在 Azure 上配置的自定义 Windows runner 在 Windows 上进行构建。这是由 Prefix.dev 赞助的。以下是相关的拉取请求

编译器和运行时​

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 保持兼容，达到罕见的极端情况），我们可以只增加全局 pinning 中的版本，它将随着 feedstock 被重新渲染而缓慢地推广到生态系统中。

对于此类 ABI 兼容的升级，适用类似但更宽松的原则

  • 这些 pin 同样在全局 pinning 中定义，请参见全局固定的软件包。
  • 我们不提供任何形式的关于给定编译器版本的长期可用性的保证。
  • 当编译器即将升级时，我们通常会以公告的形式提供通知。
  • 在不承诺任何时间表的情况下，我们在 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 进行编译，以及混合编译器堆栈引起的若干复杂性，因此它正逐渐被淘汰。

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

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

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

对于 Windows，我们会在较长时间内保持使用较旧的编译器，因为使用较新的工具链将迫使每个想要在本地使用 conda-forge 工件进行开发的人员使用至少与新工具链一样新的工具链。您可以在此关于更新到 vc142 工具链的 issue 中找到有关此主题的更多详细信息。

用于 linux-* 平台的 CentOS sysroot​

我们目前重新打包来自适当版本的 CentOS/AlmaLinux 的 sysroot，以供我们的编译器使用。这些 sysroot 文件在 sysroot_linux-* 软件包中可用。这些软件包的版本号与它们打包的 glibc 版本相匹配。这些版本对于 CentOS 7 为 2.17，对于 AlmaLinux 8 为 2.27，对于 AlmaLinux 9 为 2.34。

输出验证和 Feedstock Token​

在撰写本文时，anaconda.org 不支持生成 API token，这些 token 的范围限定为允许上传某些软件包但不允许上传其他软件包。为了保护 feedstock 上传，例如，为了防止 numpy feedstock 的维护者推送 python 软件包，我们使用软件包暂存过程并发布秘密 token，每个 feedstock 都有唯一的 token。此过程的工作方式如下。

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

我们考虑以下两种情况

新输出名称的软件包验证失败​

添加到现有 feedstock 的新软件包不会自动注册，以防止拼写错误抢注和其他恶意活动。软件包输出在 feedstock 创建期间添加。如果您将软件包从一个 feedstock 移动到另一个 feedstock，添加输出软件包或更改软件包的名称，您需要请求通过 admin-requests 仓库将新的软件包名称添加到您的 feedstock 中。

在极少数情况下，软件包名称可能会以定义明确的方式定期更改（例如，libllvm18、libllvm19 等）。在这种情况下，您可以使用我们的 admin-requests 仓库添加与新软件包名称模式匹配的 glob 模式。我们使用 Python fnmatch 模块语法。与这些模式匹配的输出软件包将自动为您的 feedstock 注册。

现有输出名称的软件包验证失败​

我们尝试通过在 feedstock 中的提交/issue 上发表评论来向用户报告此过程中的错误。有时这些报告会失败。如果您认为您在上传时遇到问题，请务必检查/尝试以下事项

  • 确保在您的 conda-forge.yml 中设置了 conda_forge_output_validation: true。
  • 通过将空提交推送到 feedstock 来重试软件包构建和上传。
  • 在 feedstock fork 的 PR 中重新渲染 feedstock 并合并。
  • 通过我们的 admin-requests 仓库请求重置 feedstock token。

软件包构建的阶段和涉及的基础设施​

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

首次提交到 staged-recipes​

conda-forge/staged-recipes 仓库使用多个基础设施组件。

在拉取请求中

  • 软件包构建管道。这些管道与在 feedstock 中运行的管道略有不同（它们不是由 conda-smithy 自动生成的，但它们确实使用相同的底层组件）。
  • linter 由 conda-smithy recipe-lint 提供，由 @conda-forge-admin 运行。
  • 自动标记逻辑，由 Github Actions 工作流程运行。

涉及的身份验证服务

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

将 staged-recipes 中的新 recipe 转换为其各自的 feedstock 是在 admin-requests 运行的 cron 作业中完成的。有关更多详细信息，请参见 admin-requests。作为 feedstock 创建的一部分，新的 feedstock 接收一个 webhook，将其与 Web 服务连接起来。

Feedstock 更改​

feedstock 可能由于多种原因而接收更改。

推送到 main 或其他分支

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

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

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

...并由...关闭

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

在打开的拉取请求中

  • 构建管道（更多信息请参见下方）。
  • linter 由 conda-smithy recipe-lint 提供，由 @conda-forge-admin 运行。
  • @conda-forge-admin, please... 命令评论，由 @conda-forge-admin 回答。

在 issue 中

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

软件包构建​

构建 conda 软件包的管道用于拉取请求和 main 及其他分支中的推送事件。唯一的区别是，在拉取请求期间构建的软件包不会上传到暂存通道。在所有 feedstock 中保持这些管道的更新涉及多个仓库

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

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

  • Azure DevOps Pipelines
  • Travis CI
  • Circle CI
  • Appveyor
  • 自托管的 Github Actions runner

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

提示

conda-smithy 支持更多 CI 提供程序。请查看其仓库以获取更多详细信息。

涉及的身份验证服务

  • Anaconda.org 上传到 cf-staging

软件包验证和发布​

一旦在 main（或其他分支）上构建完成，conda 软件包将被上传到一个名为 cf-staging 的中间渠道。从那里，我们的 Web 服务 (conda-forge/conda-forge-webservices) 将执行以下操作

  • 逻辑检查 feedstock 令牌以验证请求的合法性。
  • 逻辑检查 cf-staging 上软件包的哈希总和，以对照 CI 中计算的值，确保要复制的工件是相同的。
  • 逻辑检查是否允许 feedstock 使用 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 blob 合并到一个 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 作为常规 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 服务。

组织​

信息

这些组织存在，但不再 активно 使用

团队​

conda-forge Github 组织有数千个团队。其中大多数与 feedstock 相关联，但也有一些特殊的团队不是！

配置​

Bot 帐户​

信息

这些帐户存在，但不再 активно 使用

应用​

  • conda-forge-curator
  • conda-forge-webservices
信息

这些应用存在，但不再 активно 使用

  • conda-forge drone 实例

工作流程​

持续集成​

另请参阅

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

Azure Pipelines​

conda-forge 受益于 Microsoft 慷慨提供的托管 runners。

Travis CI​

Cirun​

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

使用 @conda-forge-daemon 配置。

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

信息

例如，这允许为选定的 feedstocks 访问启用 GPU 的 runners，如 https://github.com/Quansight/open-gpu-server 中所述。

Github Actions​

已停用的服务​

交付和分发​

Anaconda.org​

Docker Hub​

Github Packages​

Github Releases​

Quay​

服务器​

Heroku​

其他服务​

脚注​

  1. 极少数软件包由于特殊的资源要求而无法通过 CI 构建。这些软件包可以按照 CFEP-3 中规定的规则手动构建和上传。↩