Open merlinz01 opened 2 weeks ago
Thank you for suggesting this. I am looking into it.
@merlinz01 if you are already using that in an existing workflow. Can you share some statistics how much time is saved by also caching the python interpreters vs. always downloading them again?
Sure, once I'm done pulling the 209MB updated docker image for act over my <1MB/s connection :).
This is using act on my local machine. I realize that on a hosted actions runner it might be more efficient not to cache.
When I cache all the dependencies but not the Python install, and the cache exists, my test suite takes 50 seconds. When I cache both the dependencies and the Python install, and the cache exists, my test suite takes 18 seconds.
I'm always in favor for adding new functionalities if it helps users but otherwise want to keep the codebase as small as possible. So can you help me to understand the usecase a bit better?
On self-hosted runners the python interpreter should be "cached" anyways. On GitHub hosted (ephemeral) runners the question is if caching is more efficient than downloading it fresh every time.
Did I miss a usecase?
On self-hosted runners the python interpreter should be "cached" anyways. On GitHub hosted (ephemeral) runners the question is if caching is more efficient than downloading it fresh every time.
Correct. The use case this would be targeted at is running jobs locally via the act tool on one's development machine.
To confine this caching to that context, you can specify it like this:
cache-python-with-dependencies: ${{ env.ACT == 'true' }}
This cache action works to cache the Python installs:
but are you in favor of adding another input to do put the Python installs in the same cache as the dependencies?
E.g.: