使用 rclone 或 restic 或类似方法在构建之间存储差异缓存以实现持续集成 有没有现成的问题解决方案？您如何优化大型构建？

编程问答 2022-04-30

问题描述

在 CI 上缓存的常用方法是将文件存储存档，然后将其推送到某个存储，稍后下载并解压缩。很简单。

考虑来自https://github.com/actions/cache

的例子 
- name: Cache multiple paths
  uses: actions/cache@v2
  with:
    path: |
      ~/cache
      !~/cache/exclude
    key: ${{ runner.os }}-${{ hashFiles('**/lockfiles') }}

这段代码声明了什么？它说：“请尝试恢复我的缓存，排除其中一些具有 ubuntu-abfacada123456 之类的名称，然后执行其他操作并以相同的名称结束作业存储缓存”。
我们也可以提供

    restore-keys: ${{ runner.os }}-*

在找不到与 key 完全匹配的情况下，获取与该模式对应的最新可用缓存。

由于其简单明了，这是最广泛的缓存方法之一。

让我介绍一下我的问题。我有一个很大的 C++ 项目，有很多依赖项。它分几个阶段构建，还有很多事情要做得更快。
简而言之，构建包括：

  • 准备 docker 镜像
  • 构建由 vcpkg 管理的依赖项
  • 利用 ccache 使用 cmake 构建项目
  • 运行测试

有3个点要缓存

  • docker 镜像层；大约 1.4Gb，??压缩
  • vcpkg 下载、构建数据、安装 build-root；大约 5Gb，1.4Gb 压缩
  • 项目的ccache；高达 8Gb，2Gb 压缩

我已经尝试在 GitLab CI 和 GitHub Actions 上使用常规和常用的缓存技术。对于如此大量的数据，它们的效率不够高。默认缓存存储经常溢出和旧但仍删除实际档案。

CI 假设多个拉取/合并请求、提交、分支的构建；计划运行和手动运行。因此总缓存大小超过了通常的报价。

问题

  1. 存储几乎相同的文件需要太多的存储空间。从构建到构建的差异小于缓存大小的 5%，通常高达 1%
  2. 归档 5Gb 的构建数据，然后将其从构建机器上传到远程持久存储需要太多时间
  3. 带有缓存存档的存储溢出的频率比数据过时的要多
  4. 全新初始化的干净构建机器仍然需要下载完整的缓存，但下载和解包时间总是比存档和上传要少得多。

例如，我的 5Gb 的 vcpkg build_dir 在 1 分钟 40 秒内下载和上传，但存档和上传需要 4 分钟 45 秒。我们很少更改 vcpkg，通常不会更改上传。

所以任务是减少网络流量。

解决方法

我想使用一些备份/恢复实用程序，如 rclone 或 restic 来存储差异数据。

工作流程几乎相同：

  • 下载缓存；
  • 做一些事情，即构建/重建，假设这一步也自动检测要重建的内容；
  • 上传更新的缓存，唯一的区别；
  • 用标签标记上传的快照以备将来使用：日期、分支名称、内部版本号等。

关键问题是检测要下载哪个快照。
让我们考虑下一个用例。给定从分支 A 到分支主的 PR。 Branch-A仍在建设中，开发商经常推动。 PR 的每个下一个构建都应该使用前一个构建的缓存。 PR的第一个构建是指基础分支的缓存。

问题来了

有没有现成的问题解决方案？

您如何优化大型构建？

解决方法

暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！

如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。

小编邮箱:dio#foxmail.com (将#修改为@）

c++cachingcachingcontinuous-integrationrclone