Improve the caching of LFS objects to reduce the bandwith usage. #56
Conversation
There was a problem hiding this comment.
Looks to me like this would work, based on https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#matching-a-cache-key 🙂 Just reiterating the example in the docs to make sure I understand it correctly: when the cache key does not match (i.e. when files get added/removed, because the key is generated based on the hash of the sorted list of LFS assets), the restore-keys: property will restore the latest version of any cache matching the prefix, which should™ be the last version before the current commit on the current branch (or the default branch, if it is the first commit of a branch).
And with the second commit of this branch, it appears like this works, when I look at the GitHub action log 😄 (The fact that git lfs pull has no output does not say much, because it also didn't have output when running on the first commit of this branch, but the fact that it downloads the cache should be enough 🙂 Also, the Git LFS Pull action now ran in 17s with the cache instead of 37s without the cache, which is still not as fast I would expect, but fast enough, I hope? 😛)
@maartenweyns Systems Maarten, do you want to double-check? 🙂
|
It seems to me, looking at the timing of the 3 builds that his will solve the cache misses if lfs assets are added. |
|
Looks indeed like this should at least fix the bandwidth for the workflow. Nicely done! |
Might resolve #55.