创建和托管您自己的 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 部分主要推荐用于您自己的专有包，而不是开源的 ConanCenter 包。

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

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

此流程相对简单，并具有许多优势，可以缓解之前描述的风险

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

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

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

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

从上游更新

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

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

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

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

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

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