小编mar*_*ych的帖子

我有一个合理大小的Bazel项目,我注意到bazel fetch //...CI大约需要5分钟(约100个档案,总共约3 GB).

我首先认为这是由于下载所有外部包,但我排除了这种可能性通过镜像所有内容的本地机器上,主机本地HTTP服务器,并更新WORKSPACE到使用那些原来的网址是勉强的速度比实际上下载内容.

我也尝试将git repo和bazel输出库放在tmpfs上以避免任何磁盘I/O,但这根本没有帮助.

这个--experimental_repository_cache论点似乎有所帮助,但并不显着.

我在抓取过程中观察了和htop,dstat以及本地镜像服务器日志的输出,发现了一些奇怪的东西:

• CPU大部分时间处于空闲状态.在一开始的几秒钟内有大约50%的CPU使用率(在56核心机器上),我猜测它正在构建图形的东西.除此之外,通常有1个核心在100%使用,我猜测是解压缩档案.
• 本地镜像的服务器日志表明存档以"突发"(一次只有几十个)下载,这意味着它不会在下载时被阻止.

所有这些都向我表明档案是并行下载的,但是解压缩它们是连续完成的,这最终会变慢,因为解压缩是不平凡的,但这纯粹是猜测.

从另一端来看 - 我bazel fetch //...在CI中做的唯一原因是进行rdeps查询//...以确定构建/测试的内容.我们不是隐式地进行查询fetch //...,而是提前完成,因此错误消息更清晰,我们可以在失败时重试,对查询有更严格的超时等.有没有更好的方法来确定哪些目标受影响基于git diff如此我们可以避免fetch //...或至少与建筑并行完成吗？

任何减少获取依赖项的时间的建议都将非常感谢!