创建和托管您自己的 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 中。如果您愿意,可以检查和审计这些更改,分析差异(一些修剪掉您未使用配方差异的自动化工具可能会很有用)。
启动上述过程将有效地重建所需的新二进制文件。如果您的配方未受更改影响,则该过程将避免重建二进制文件(归功于
--build=missing
)。您可以将包上传到辅助的“测试”服务器仓库。然后针对该测试服务器测试您的项目,以检查您的项目是否未被新的 ConanCenter 包破坏。
一旦您验证新包一切正常,您可以将它们从辅助“测试”仓库复制到您的主生产仓库,开始使用它们。