Cache Management with GitHub actions
Вставка
- Опубліковано 31 січ 2023
- Caching dependencies and other commonly reused files enables developers to speed up their GitHub Actions Workflows and makes them more efficient. Let's look at how cache management works, as well as some new features that were just added. And, let's give a little explanation of where the heck I am recording from. Here we go!
Demo Repo:
github.com/ChampBVT/actions-dump
Article:
oozou.com/blog/ci-cd-tips-imp...
Docs:
docs.github.com/en/actions/us...
Find Me:
Website: mickeygousset.com
GitHub: github.com/mickeygousset
Twitter: / mickey_gousset
Twitch: / mickeygousset - Наука та технологія
Thanks, setting up caching with this guide was a breeze. Easy to follow and very clear.
I was able to cut down my npm install time from 2 minutes to 3 seconds when the cache hits!
Super clear! Thanks for this
Thank you!
Great video! Thanks!
Thank you!
Thanks a lot!!
Why is your camera output set to 10FPS? I like your content, but you should look into the FPS settings.
Hey! Thanks for the feedback. I will look into that as that would be an error on my part. I just upgraded all the equipment I use so I’m hoping the new equipment will solve that problem.
Hey great video!
I was wondering, imagine you're using megalinter for instance, could you cache the pulled image so it is "reusable" everytime you run the workflow?
You "could", but normally the cache is not meant for storing container images. If you keep it under 10 GB, then its doable.
@@MickeyGousset How would you go about it if you don't mind me asking?
Ideally as the image is pulled I would like to cache it however I can't seem to quite understand which path to specify to do so.
Is there a way to get this functionality to work with self hosted runners? I have output of a workflow in the range of 20-30GB in a folder that needs to be referenced by the next run of the workflow. Running self hosted runners in EKS cluster, and have been trying to mount EFS volume to hold the data, but wondering if this might offer a better solution.
That’s going to be too big for repo caching, as the max cache size is 10 gb.
You’ll have to figure out something else, such as storing it on a shared volume, which is the direction you are headed I believe
Is this cache global to all PRs (as long as the yarn.lock files don't change) or is it per PR?
Also, wouldn't we gain more time by still using the caching properties of the actions/setup-node in the advanced version?
How do you restore the cache between multiple jobs of the same workflow?
Cache is “global” to all PRs in a repository, as the cache exists at the repository level.
Cache is restored based off the cache name so if multiple jobs use the same cache name, they will access the same cache.
@@MickeyGousset thanks for you quick answer. And thanks for the video :)!
Does this work with NPM as well? For me even if the cache is restored, the npm ci still takes the same amount of time.
Yes it works with npm, with anything you want to cache. Hmmmm, I would have expected it to speed up the time.
Things to check:
Are you caching the right files?
Is the cache getting created?
Is the cache getting used?
What is the cost involved to caching? I understand the 10 Gb limit per repo, i just want to know whether it is billed or is it a free offering? We have GitHub enterprise license and most of our repos are private.
No cost
Thanks for the reply!@@MickeyGousset
Caching node_modules is not recommended as per the docs. What do you think about this?
@akhilr94 drop me a link to the docs, and I'll talk to some people and get an opinion.
Caching node_modules can speed up your workflow runs by reusing the installed dependencies instead of downloading and installing them every time. However, caching node_modules also has some drawbacks, such as:
It can increase the size of your cache and the time it takes to upload and download it
It can cause issues if you update your dependencies or switch between different package managers
It can expose sensitive information if you store any in your node_modules folder
So I guess it depends....
@@MickeyGousset Also, I tested out both versions. node_modules has less cache size than yarn global cache. Also since I'm on self hosted runner, I have to pay the penalty of downloading and uploading the cache from github runner. This network cost is leaning me towards caching node_modules altho the recommended approach is caching the global cache. The only reason against using node_modules is the node version inconsistency (according to the docs), but like you mentioned in the video, we can make the node version a part of the key to make it consistent.
What about caching the apt
Can you explain what you mean a little more?
@@MickeyGousset I have apt packages in Ubuntu/Linux such as python3 and pip3 dependencies, I want to cache them for faster build times.
@@sketchwaretagalogtutorials gotcha. Then it should just be a matter of finding the location on the build server where you have those files and adding them to the cache
@@MickeyGousset nice. Thanks.