-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Advice for how to cache the conda installation? #13
Comments
If you do not use the ‘latest’ but just do not define that key this action will use the bundled conda in the container which is good enough for most use cases. I will look into caching and document avaliable env variables so you can use it as needed. Will need a couple of days though! Thanks for making this action better and the kind words |
Good to know!
No rush! Thanks for looking into this. |
@dhimmel just to check, did the situation improve with - name: Install Environment
uses: goanpeca/setup-miniconda@v1
with:
activate-environment: manubot
environment-file: build/environment.yml
auto-activate-base: false ? |
Removed I don't think that installing miniconda is actually taking a large amount of the time. Most of the time is being consumed by having to resolve the dependencies when installing the |
I could add beta support for using mamba instead of conda 🤷♂ https://github.com/QuantStack/mamba ? |
Not sure about mamba. Not sure how likely it would be to behave differently than conda and cause headaches. I was thinking more along the lines of the solution in this CI config. Are there directories we can cache that would cache the package download or dependency files / resolution steps? Another example at theochem/cgrid#8 (comment) |
Yes and no. Github imposes size limits on the cache you can store so if your dev environment requires too many packages it will fail. In the meantime, could you try running These values will change for different OSes, but those are the directories that store the downloaded packages. |
Aslo conda solver is becoming horribly slow for some time now (years?) so that is why mamba exists. |
Also if you are not testing for different python versions (or different packages versions) and always run the same thing then you could try to cache the |
Take a look at manubot/rootstock#319. It seems like it does save above 40 seconds by caching the According to the build log, the cache size is ~193 MB. So quite hefty but still fits. Now I wonder whether there is a way to cache more to cut down on the remaining time (which I think is probably dependency management).
This is the case, but even if not I think creating different cache keys for different OSes solves the problem. |
Sure, I mean if you are running the linux container to test things with Py37 and py38. Caching pkg_dir will only work if the conda packages are no arch, or not python dependencies, otherwise the caching won't help much so it really does depend on your workflow and your environment. As I said, conda has become really slow :-\ |
what is the guideline to enable cache? |
Correct do not specify miniconda versión at all and dont activate the conda autoupdate version. That will use all that is installed with the container. |
We use this action for Manubot, see workflow and example build. It's great, thanks for making it! Our current configuration is:
In manubot/rootstock#316, I'm looking into using
actions/cache
to cache a directory of data created during action runtime.However, the slowest part of our build is often installing the conda environment, which currently takes about 100 seconds of the 200 second total time. So I was wondering if the conda environment would be cacheable.
For example what about the following:
Basically our goal is use a pre-existing conda installation unless our environment.yml specification is changed. @goanpeca does that sound like a good idea? Any advice on what directory we should cache and how to configure this action to use a cached directory?
The text was updated successfully, but these errors were encountered: