创建和托管自己的 ConanCenter 二进制文件

在您自己的服务器上托管所需软件包的副本，可以通过仅从 ConanCenter 下载二进制文件，然后将它们上传到您自己的服务器来完成。然而，完全拥有完整的供应链并在您自己的 CI 系统中创建二进制文件要好得多。因此，在生产环境中使用 ConanCenter 软件包的推荐流程是：

• 创建 ConanCenter GitHub 仓库的 fork：https://github.com/conan-io/conan-center-index

• 创建您项目所需的软件包和版本列表。此列表也可以添加到 fork 中，并在那里维护（当团队需要时，可以通过 PR 添加和删除软件包）。

• 创建一个脚本，该脚本首先 conan export 您列表中的所有软件包，然后 conan create --build=missing 创建它们。不要为这些软件包添加 user/channel，直接使用 zlib/1.2.13 而无需 user-channel 要简单得多。user/channel 部分主要推荐用于您自己的专有软件包，而不是开源的 ConanCenter 软件包。

• 将您构建的软件包上传到您自己在生产环境中使用的服务器，而不是 ConanCenter。

这是基本的流程思路。我们将尽快添加示例和工具来进一步自动化此流程。

此流程相对直接，并且具有许多优点，可以减轻之前描述的风险：

• 没有中心存储库的故障会影响您的构建。

• 中心存储库中的任何更改都不会破坏您的项目，您可以完全控制何时以及如何将这些更改更新到您的软件包中（如下所述）。

• 您可以自定义、适应、修复并完美控制使用的版本，并在几分钟内而不是几周内发布修复。您可以应用不会在中心存储库中被接受的自定义。

• 您完全控制二进制供应的整个链条，从源（配方）到二进制文件，实际上消除了中心存储库的大部分潜在的供应链攻击。

从上游更新

仍然可以从上游 conan-center-index Github 仓库进行更新，并且可以以完全受控的方式进行。

• 将上游 conan-center-index 主分支的最新更改合并到您的 fork 中。

• 您可以选择性地检查和审计这些更改，分析 diff（一些能够修剪您不使用的配方 diff 的自动化可能很有用）。

• 执行上述过程将有效地重新构建所需的新的二进制文件。如果您的配方不受更改的影响，该过程将避免重新构建二进制文件（感谢 --build=missing）。

• 您可以将软件包上传到一个次要的“测试”服务器存储库。然后，针对该测试服务器测试您的项目，以检查您的项目是否因新的 ConanCenter 软件包而损坏。

• 一旦您确认新的软件包一切正常，您就可以将它们从次要的“测试”存储库复制到您的主生产存储库以开始使用它们。