Should all caches, not just disk-cache, take custom keys? (or one universal key for all caches)

[calebzulawski]

If you have multiple jobs (or a matrix), I find that the bazelisk and repository caches conflict on their initial creation. In the case of bazelisk, each job attempts to write an identical bazelisk cache, one succeeds, and the others all report a warning. This also occurs for the repository caches, but I think these shouldn't even be shared. Different jobs might build different targets and end up fetching different dependencies.

One solution might be to add a cache-key option that all caches use (but allow disk-cache to still override this, for backwards compatibility). An alternative solution would be to try to hide that warning for bazelisk, and recommend using an initial bazel fetch job to populate the cache.

Some example warnings:

[p0deje]

An alternative solution would be to try to hide that warning for bazelisk

It makes sense. I always thought that it didn't matter which job uploaded the cache amongst the concurrent ones. I think that GHA used to hide these warnings too.
Unfortunately, I don't see a way in @actions/cache to suppress these warnings.

recommend using an initial bazel fetch job to populate the cache.

Maybe we should let repository cache grow and GC it similar to how you suggest handling disk cache in #71? This way all the jobs would contribute to the same cache and there will be no need for bazel fetch or separate repository caches?

[calebzulawski]

Unfortunately, I don't see a way in @actions/cache to suppress these warnings.

We could probably catch the ReserveCacheError and at least conditionally rethrow it

Maybe we should let repository cache grow and GC it similar to how you suggest handling disk cache in #71? This way all the jobs would contribute to the same cache and there will be no need for bazel fetch or separate repository caches?

Maybe we should do that, but I don't think it solves the issue that all jobs have the same cache name despite being possibly unrelated. I think we still need to expose a job key that's configurable per-job/matrix combination.

[p0deje]

We could probably catch the ReserveCacheError and at least conditionally rethrow it

We won't even see this error, it's caught internally by actions/cache https://github.com/actions/toolkit/blob/7ae578ddd11b9e33db1daaad2ffb39e1ffeada3f/packages/cache/src/cache.ts#L573

Maybe we should do that, but I don't think it solves the issue that all jobs have the same cache name despite being possibly unrelated. I think we still need to expose a job key that's configurable per-job/matrix combination.

You are right, we should probably introduce a new input repository-cache-prefix or repository-cache-key. The overall API for disk/external/repository gets a bit messy, but we can find a better interface until reaching v1

• disk-cache accepts a boolean to enable/disable or a string that is used as the cache prefix
• external-cache accepts a boolean to enable/disable or a YAML manifest of repo-name -> file path for the cache key hash
• repository-cache accepts a boolean to enable/disable or a string that is a file path used in calculating the cache key hash

---

On a side note, I wish we could make #21 work, this would eliminate a whole bunch of issues for disk cache (and eventually remote) as we wouldn't need to implement GC or deal with the same cache keys.

[calebzulawski]

Do you mind if I make non-backwards-compatible changes to the action inputs in #71? I can try some of these things.

[p0deje]

@calebzulawski I won't mind, let's just document the migration instruction for breaking changes.