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

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

• 创建 ConanCenter Github 仓库的分支：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。

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

此流程相对简单明了，并且具有许多优点，可以减轻之前描述的风险

• 中央仓库中断不会影响您的构建。

• 中央仓库的更改不会破坏您的项目，您可以完全控制何时以及如何在您的软件包中更新这些更改（如下所述）。

• 您可以自定义、调整、修复和完美控制使用的版本，并在几分钟而不是几周内发布修复程序。您可以应用中央仓库不接受的自定义项。

• 您可以完全控制二进制文件供应链，从源（recipes）到二进制文件，实际上消除了中央仓库的大部分潜在供应链攻击。

从上游更新

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

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

• 您可以检查和审核这些更改（如果您愿意），分析差异（一些自动化工具可以修剪您不使用的 recipes 的差异，这可能很有用）

• 启动上述过程将有效地重建所需的新二进制文件。如果您的 recipes 未受更改影响，则该过程将避免重建二进制文件（感谢 --build=missing）。

• 您可以将软件包上传到辅助“测试”服务器仓库。然后针对该测试服务器测试您的项目，以检查您的项目是否被新的 ConanCenter 软件包破坏。

• 一旦您验证了新软件包一切正常，您可以将它们从辅助“测试”仓库复制到您的主生产仓库以开始使用它们。