You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been using this action on a repository for a while, and the size of the github actions cache has been continuously increasing.
It's now up to ~1.3 GB, and most of the action's time is spent downloading and re-uploading the cached directories. A recent run spent 56s fetching the cache, 18s linting, and 1m27s re-uploading the cache. (This is for a reasonably small repository; the total size of code and all downloaded dependencies is ~20 MB.)
I believe this is primarily because the package cache never prunes old dependencies, so as dependencies are updgraded we end up with all dependency versions ever used by the project in the package cache.
It looks like the github actions cache key is generated as golangci-lint.cache-[sequence num]-[go.mod checksum] where the sequence num rotates every 7 days. When restoring we're passing the following as restore keys:
This means that even when the sequence number rotates, we'll still restore the previous cache because of the golangci-lint.cache-, use it for the build, then re-upload using a new sequence number. As a result, all the cached packages are carried forward as we never start with a clean build.
If there were a way to have go prune the package cache to remove unneeded packages that might be a good option to run at the end of the build before uploading the cache, but I don't think such an option exists. (You can only fully clear the package cache and regenerate it, but of course doing this on every build would defeat the purpose of having the cache at all.)
I think the best solution here is probably just to remove golangci-lint.cache- from the restore keys. This will force a clean build every time the sequence number rotates (once every 7 days) so we'll avoid continuously carrying forward all prior dependencies of the project. (Based on the comment in the code I think that may have been the intention initially.)
The text was updated successfully, but these errors were encountered:
I've been using this action on a repository for a while, and the size of the github actions cache has been continuously increasing.
It's now up to ~1.3 GB, and most of the action's time is spent downloading and re-uploading the cached directories. A recent run spent 56s fetching the cache, 18s linting, and 1m27s re-uploading the cache. (This is for a reasonably small repository; the total size of code and all downloaded dependencies is ~20 MB.)
I believe this is primarily because the package cache never prunes old dependencies, so as dependencies are updgraded we end up with all dependency versions ever used by the project in the package cache.
It looks like the github actions cache key is generated as
golangci-lint.cache-[sequence num]-[go.mod checksum]
where the sequence num rotates every 7 days. When restoring we're passing the following as restore keys:golangci-lint.cache-
golangci-lint.cache-[sequence num]-
golangci-lint.cache-[sequence num]-[go.mod checksum]
This means that even when the sequence number rotates, we'll still restore the previous cache because of the
golangci-lint.cache-
, use it for the build, then re-upload using a new sequence number. As a result, all the cached packages are carried forward as we never start with a clean build.If there were a way to have go prune the package cache to remove unneeded packages that might be a good option to run at the end of the build before uploading the cache, but I don't think such an option exists. (You can only fully clear the package cache and regenerate it, but of course doing this on every build would defeat the purpose of having the cache at all.)
I think the best solution here is probably just to remove
golangci-lint.cache-
from the restore keys. This will force a clean build every time the sequence number rotates (once every 7 days) so we'll avoid continuously carrying forward all prior dependencies of the project. (Based on the comment in the code I think that may have been the intention initially.)The text was updated successfully, but these errors were encountered: