Skip to main content

The feedstock

Feedstock 是一个配方的家；在多输出配方的情况下，它可能生成多个 conda 制品。Feedstock 是配方生命周期中大多数事件发生的地方。

初始化​

Feedstock 仓库是在 staged-recipes 中合并后创建的（有关该过程的详细信息，请参阅Feedstock 创建）。

软件包构建图​

软件包构建可以由多个事件触发，这些事件将在下一节中描述。在所有这些情况下，都会发生以下顺序。

注意
  1. 对于 Linux 和 noarch 软件包，构建本身在 CI 上的 Docker 容器中进行。在 macOS 和 Windows 上，CI 运行器系统镜像在稍微调整后使用。
  2. 本地验证在 CI 上进行，并通过查阅feedstock-outputs 仓库来检查构建期间生成的制品是否对此 feedstock 是允许的。
  3. 服务器端验证本质上与 2 相同。它在分发基础设施内部重复进行，以防止在 feedstock 级别上可能发生的有意或无意的干扰，因为 feedstock 级别更容易访问。
  4. 仅当本地验证（2.）成功时，才会触发上传。此外，它仅在特定条件下执行，例如对于 main 中的提交，但不在 PR 中。请注意，如果服务器端验证（3.）失败，软件包也可能无法从 cf-staging 传输到 conda-forge。如果 2. 成功而 3. 失败，这通常是由于令牌过期。

触发新构建的事件​

软件包构建要么作为 PR 的一部分触发，要么在 feedstock 仓库中分支的提交时触发（这反过来通常源于 PR 的合并）。

警告

feedstock 中任何分支上的任何提交都可能导致软件包的构建和发布。为避免不当软件包的随意发布，开发分支绝不能添加到 feedstock 仓库中。相反，它们存在于 feedstock 仓库的分支中，并且相关的工作仅通过拉取请求添加。

几乎所有对 feedstock 仓库的更改都是通过 PR 执行的。这对于手动维护者干预和 conda-forge 自动化都是如此。

信息

可以直接向分支添加提交。这偶尔用于使用空提交重新触发失败的 CI 运行

git commit --allow-empty -m "Retrigger CI"

手动提交的 PR​

这些 PR 不是自动化的。任何 Github 用户都可以通过 fork feedstock、从 main 创建新分支并添加必要的提交来实现预期的更改（例如，构建新版本或添加新平台）来打开新的 PR。

是否审查、批准和合并 PR，或者拒绝并关闭 PR，由 feedstock 维护者和/或 conda-forge/core 团队决定。

在 PR 的生命周期中，将发生一些自动化操作

  • linter 将扫描配方的状态，以要求更改并提出改进建议。如果未满足，这将导致 CI 运行失败。Linter 失败绝不能在没有明确的核心团队批准的情况下被忽略。
  • PR 模板将要求您每个 PR 至少重新渲染 feedstock 一次。这将确保 CI 配置是最新的，以及其他事项。您可以在任何评论中使用机器人命令 @conda-forge-admin, please rerender，或者通过 conda-smithy rerender 在本地执行。

自动化 PR​

在许多情况下，conda-forge 自动化将创建 PR。在这些情况下，审查和合并 PR，从而触发仓库上的操作，通常是 feedstock 维护者的特权。

分支上的每个提交都将触发 ci，除非其提交消息包含标签 [ci skip]，这可以通过将其包含在 PR 标题中来实现 PR。某些提供商在 PR 期间忽略此标签，但在由 main 等分支触发的运行中遵守它。

版本更新​

当上游发布新版本时，需要创建一个 PR，以执行对 feedstock 的必要更新。至少，这包括更新上游源制品的版本、下载 URL 和哈希值。此外，可能还需要对配方进行其他更改，例如更新的依赖项要求、软件包的 noarch 状态的更改或构建或测试脚本的调整。虽然这些最后的更改通常需要由维护者完成，但 conda-forge 具有复杂的功能来添加初始版本更新 PR。

它是如何工作的？

这在 cf-scripts 的 CI 中分两个步骤完成。

首先，版本信息从上游源更新，并存储在 cf-graph-countyfair 仓库中，更具体地说是在 versions 目录树中，按哈希值嵌套，每个软件包一个文件。

其次，主要的机器人 CI 作业，cf-scripts 中的 bot-bot 操作为所有在上游有新版本的软件包创建 PR。这是一个关于如何完成此操作的简化图。有关完整图片，请阅读下方。

提交后，由 feedstock 维护者检查 PR，进行任何必要的调整，并将其合并到 feedstock 分支中。

此版本更新是 migrator 的一个示例。在以下部分中阅读有关 migrator 的更多信息。

为 migrator 重建​

版本更新是 migrator 的一个示例。实际上，有更多场合和理由来更新配方，例如，重新编译一个原本未更改的二进制程序或库，以链接到较新版本的依赖项，或添加对新架构的支持。这种用例由 migrator 处理，migrator 是一种通用的配方重写工具。

关于 auto-tick 的作用，更完整的描述如下

Migrator 是一种强大的机制，几乎可以进行任意配方更改。它们是用 Python 编写的，当前的 migrator 集可以在 regro/cf-scripts 仓库中找到。