R 4.0 迁移回顾
虽然 R 4.0 的迁移在功能上已经完成很长一段时间了，但最近 r-java 及其依赖项的迁移提供了一个很好的机会来撰写一篇关于 conda-forge 中大规模迁移的技术问题的回顾，以及我们如何解决这些问题。
R 4.0 迁移重建了 conda-forge 中所有以 r-base 为要求的软件包，包括超过 2200 个 feedstock。conda-forge 中如此规模的迁移面临着几个障碍。首先，由于每个 feedstock 都是一个单独的 GitHub 仓库，因此需要合并超过 2200 个拉取请求 (PR)。其次，anaconda.org 上的 conda-forge 软件包位于 CDN（内容分发网络）之后。这项服务降低了 Anaconda Inc. 的 Web 托管成本，但也引入了大约 30 分钟的延迟，从软件包上传到 anaconda.org 到它使用命令行中的 conda 显示为可用状态。因此，即使软件包的依赖项已经构建完成，我们也必须等到它们出现在 CDN 上，然后才能成功发布下一个 PR 并使其正确构建。最后，现有的机器人和 conda 基础设施限制了迁移的吞吐量，部分原因是 conda 求解器的速度。
鉴于 R 4.0 迁移的规模，我们借此机会尝试使用一系列新技术来加速大规模迁移。主要的增强功能包括使用 GitHub Actions 自动合并 PR，使用 mamba 快速检查软件包环境的可解性，以及为 autotick 机器人启用长时间运行的迁移作业。总而言之，R 4.0 的大部分 feedstock 在不到一周的时间内被重建，许多 PR 从发布到合并在 30 分钟或更短时间内完成。这些对 autotick 机器人和 conda-forge 基础设施的增强功能可用于增强未来的迁移（例如，Python 3.9）并减轻 feedstock 的维护负担。
自动合并 conda-forge PR
在 conda-forge 的典型迁移中，我们向 feedstock 发布一个 PR，然后要求 feedstock 维护者确保它通过并合并它。在 R 4.0 迁移的情况下，conda-forge 上 R 软件包的维护者在绝大多数 feedstock 上使用维护团队（即 @conda-forge/r）。这个团队很小，因此手动合并 2000 多个 PR 是一项庞大的任务。因此，在他们的许可下，我们将 conda-forge 自动合并功能添加到他们维护的所有 R feedstock 中。自动合并机器人依赖于 GitHub Actions，能够自动合并来自 autotick 机器人的任何 PR，这些 PR 通过了配方检查器、持续集成服务，并在 PR 标题中包含特殊的 [bot automerge] 标记。此功能消除了等待维护者合并 PR 的瓶颈，并减轻了 R 维护团队的维护负担。
使用 mamba 检查可解性
虽然能够自动合并 PR 减少了执行 R 4.0 迁移的大部分工作，但这依赖于 PR 在首次发布时正确构建。由于 CDN 延迟和软件包依赖项的构建时间，软件包的依赖项可能在它们的所有迁移 PR 合并后不会立即可用。如果机器人在依赖项可用之前发布了软件包迁移 PR，则 PR 将因环境不可解而失败，并且必须手动重启。这种失败将抵消首先使用自动合并的任何好处。
为了控制这种边缘情况，我们使用 mamba 软件包在发布 PR 之前检查 PR 环境的可解性。mamba 是 conda 的快速替代品，可以更快地生成环境解决方案，速度快几个数量级。由于我们必须多次执行 PR 环境检查，因此极快的求解器对于使代码足够高效以作为 autotick 机器人的一部分运行至关重要。我们最终使用 mamba 尝试安装要迁移的 feedstock 生成的每个变体的依赖项。通过此检查，autotick 机器人能够发布首次尝试就通过的迁移 PR，因此可以自动合并，许多在 30 分钟或更短时间内完成。
提高 Autotick 机器人的效率
最后，我们对 autotick 机器人基础设施进行了一些升级，以提高机器人的正常运行时间和效率。首先，我们从每小时运行的 cron 作业改为一组链接的 CI 作业。此更改消除了机器人运行之间的停机时间。其次，我们开始将 autotick 机器人从一个庞大的代码块重构为一组分布式微服务，这些微服务并行执行各种独立任务。这些独立任务用于检查先前发布的 PR 的状态等，它们是单独运行的，从而使机器人可以将更多时间用于发布 PR。最后，我们优化了 PR 的内部优先级排序，以确保机器人将更多时间用于需要完成更多工作的大型迁移。更多关于 autotick 机器人基础设施的工作，包括 Vinicius Cerutti 作为 Google Summer of Code 计划一部分完成的工作，将进一步简化机器人的操作。
尽管机器人基础设施最初出现了一些小问题，但对于如此规模的努力，迁移运行得相当顺利。绝大多数迁移 PR 在我们开始后的一周内完成，这在 conda-forge 上如此规模的迁移中尚属首次。最近解决了最大的问题，修复了 openjdk 配方并从 r-java 中删除了 aarch64 和 ppc64le 构建，从而使 R 生态系统的最后一大块得以更新。
展望未来，我们为 R 4.0 迁移所做的改进似乎广泛适用于其他迁移任务，包括每年的 Python 小版本升级。这些类型的大规模迁移特别适用，因为它们通常只涉及对 feedstock 本身进行少量更改，并且通常在 CI 上失败，因为会生成损坏的软件包。更快的迁移将有助于为下游用户提供最新功能，并将过渡时间保持在最短，从而有助于促进生态系统的更大稳定性和用户期望从 conda-forge 获得的无缝体验。