GitHub: cache more things

[garymm]

also remove unnecessary remote_download_minimal. We're not using a
remote cache so it's pointless.

Change-Id: I375b456a064ccbd57d6cdc94f9b548371d92ddaf

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (2e6a83d) 82.45% compared to head (5b59f8f) 82.45%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #127   +/-   ##
=======================================
  Coverage   82.45%   82.45%           
=======================================
  Files          16       16           
  Lines         627      627           
  Branches       38       38           
=======================================
  Hits          517      517           
  Misses         94       94           
  Partials       16       16           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[garymm]

@oliverlee I'm a bit worried about this in the post-cache step:
Warning: Path Validation Error: Path(s) specified in the action for caching do(es) not exist, hence no cache is being saved.

I tried to reproduce locally but couldn't. Maybe it will be fixed once this runs on master and the cache is created.

[oliverlee]

Github actions cache cannot be updated once it is created (except for separate versions on feature branches).
https://github.com/actions/cache/blob/main/tips-and-workarounds.md#update-a-cache

This is how I handle repo cache in geometry:
oliverlee/geometry@0ada9e3
oliverlee/geometry@c3c0a34
The jobs run in the check workflow do not save repo cache.

From looking at profiling data in CI logs, ctx.download_and_extract of the llvm toolchain (which occurs in almost all CI jobs) takes ~2 mins and dominates the load+analyze phases. By setting up actions/cache/restore (which takes ~ 1 min), the load+analyze phase is reduced to a few seconds and results in ~1 minute saved overall.

Here's a snippet from a recent build:

=== PHASE SUMMARY INFORMATION ===

Total launch phase time                              1.581 s   11.32%
Total init phase time                                1.769 s   12.67%
Total target pattern evaluation phase time           0.254 s    1.82%
Total interleaved loading, analysis and execution phase time   10.326 s   73.93%
Total finish phase time                              0.035 s    0.25%
---------------------------------------------------------------------
Total run time                                      13.966 s  100.00%

https://github.com/oliverlee/geometry/actions/runs/7514778513/job/20458026966

[oliverlee]

Also, the single saved repo cache in geometry is ~4GB. I assume it will be similar here if successful since the same hermetic toolchains are used. Since each job is creating a separate cache entry, each workflow run will probably hit the cache limit and result in cache evictions.

https://github.com/actions/cache#cache-limits

[garymm]

Hmm OK I guess not sure if this is the best, but seems a bit simpler that what you did to me. I split it into "bazel disk cache" which every job writes and reads, and "bazel other" which only one job writes and everyoone else just restores.

[oliverlee]

just fyi, you will only be able to write this cache once per branch.

[garymm]

Thanks. I did not know that's how the cache action worked but I think that's fine for these.

[oliverlee]

Jobs show about 0 second duration for cache restore steps. Maybe you can try manually clearing the caches and then triggering the workflow twice?