cache backend for GitHub Actions · Issue #1947 · moby/buildkit (original) (raw)
Currently, a common method to reuse build cache in Github actions is to use cache action together with local cache exporter/importer.
This is inefficient as full cache needs to be saved/loaded every time, and tracking does not happen per blob. Also, weirdnesses like double compression happen because systems do not know about each other.
There is also currently a problem in local exporter where the cache is appended; meaning the directory keeps growing unless it is manually replaced. This should be fixed separately.
We can attempt to write a special cache backend for Github actions case where layer blobs are written to the cache service similar way as they are currently written to the registry on remote cache.
I started writing Go library that allows writing and loading blobs from the cache service. https://github.com/tonistiigi/go-actions-cache There are no docs afaics, so it is reversed engineered from typescript implementation.
Problems/Open topics:
- When parallel jobs are exporting cache together, there needs to be some kind of synchronization mechanism. Not sure what is the best method to achieve locking.
- Github cache service can not be accessed then doing local builds, even if you would provide your personal github token. So it is not a replacement for cache sharing from your CI to the users.
- Tokens for the cache service seem to be only exposed to the actions and not the inline workflow scripts. This means we can use it in
docker/build-push-actionbut not whendocker buildxis run inline. Maybe need to make a helper action that would just make the tokens available to next commands. Don't see security implication. - Ideally, cache should use zStd compression by default as gzip is very slow. This requires some low-level changes as multiple compression variants for a blob is not currently allowed. Because gzip is not deterministic, once gzip blob has been created it has to be used in cache instead as it can't be recreated.