[venus-worker] 改造 github-actions， 支持 actions/cache，降低编译耗时

[dtynn]

模块 / Components

• venus-sector-manager
• venus-worker
• 工具链 / toolchains
• 文档 / docs

描述 / Description

How I speeded up my Rust builds on GitHub ~30 times

[0x5459]

https://www.infinyon.com/blog/2021/04/github-actions-best-practices/

[dtynn]

sscache 的生效还是建立在cache key 合理规划的基础上。
https://github.com/ipfs-force-community/venus-cluster/blob/main/.github/workflows/venus-worker.yaml#L27-L37

看上去它只是一个（可能）更好的 cache 组件，不是一个更好的 cache 策略

@0x5459

[dtynn]

换句话说，如果依然依赖

      - name: Save sccache
        uses: actions/cache@v2
        continue-on-error: false
        with:
          path: ${{ matrix.sccache-path }}
          key: ${{ runner.os }}-sccache-${{ hashFiles('**/Cargo.lock') }}
          restore-keys: |
                        ${{ runner.os }}-sccache-

中的 ${{ hashFiles('**/Cargo.lock') }} 部分，那么使用它很可能 好得有限

[0x5459]

如果某个PR的改动没有修改 Cargo.lock ，还是有比较明显的效果的。 原本需要 21 分钟，使用 sccache 后 5 分钟。
另外 sccache 支持使用 S3 之类的对象存储， 用这个就应该不需要考虑 Cargo.lock 的问题。（我觉得用 actions/cache 应该也够了

[dtynn]

现在的效果就是这样啊，Cargo.lock 不变，可以应用到 cache 。问题是 cache 的命中率在 venus-cluster 的代码演进过程中显著不高。
另外还有一个潜在的问题是 常规 cache 可能会受 github 存储空间的限制，可能被动 evicted，这是我认为 sscache 可能带来改善的地方：用外部存储空间换取 cache 结果的持续存在，但是这带来额外的存储空间成本开销。

因此结论不变：
看上去它只是一个（可能）更好的 cache 组件，不是一个更好的 cache 策略

[dtynn]

基于上述可能性，可以：

1. 观察两次连续的 venus-worker action 日志（历史记录，或新触发），观察是否存在 cache key 一致，但是 cache 结果没有正确获取的情形
2. 基于 cache 预期外 evicted 的情况，量化分析成本和收益，以此决定引入 sscache 的方式、引入外部存储的类型和方式

[0x5459]

补充: sccache 已经支持 github-actions 类型的存储 https://github.com/mozilla/sccache/tree/main#github-actions； mozilla/sccache#1433; 暂时还在main分支，没发布版本。这个可以解决 hashFiles('**/Cargo.lock') 的问题。

[dtynn]

看上去，只是支持通过额外配置的方式使用 已经存在的 cache file，怎么解决了 hashFiles('**/Cargo.lock')？