provision-with-micromamba
provision-with-micromamba copied to clipboard
mamba-org
Remove or add custom-key for Micromamba-bin cache
I'm experiencing unexpected and undocumented behavior with caching. In the post install mamba step, micromamba-bin is being cached automatically with a key that is not configurable.
This creates cache bloat if the Github action job runs multiple times (ex. everyday).
Is this a known bug (I couldn't find one if so)?
...
Cache Size: ~5 MB (5504365 B)
Cache saved successfully
Cache saved with key: micromamba-bin https://micro.mamba.pm/api/micromamba/linux-64/latest Wed May 17 2023 YYY
...
Configuration step details:
...
jobs:
lint:
name: Lint dbt models using SQLFluff
runs-on: ubuntu-latest
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- name: Checkout branch
uses: actions/checkout@v3
with:
fetch-depth: "0"
- name: Micromamba environment creation
uses: mamba-org/provision-with-micromamba@main
with:
environment-file: transform-dbt/environment.yml
...
Doesn't this only create a single cache entry per day, and then old unused cache entries will be evicted when GitHub cleans them up?
Yes, after the 7 period they should be removed by Github automatically per the Github docs. Nonetheless, I was not expecting this behavior since there are super nifty download and env cache options. Since I didn't have any of cache options set to true AND was still seeing cache entries, I was confused/thought there might be a bug. Since the size of the cache is small (5mb) it's not a material issue in my specific case. However, if the cache was larger, it would become more of an issue.
The new action mamba-org/setup-micromamba that’s replacing this one doesn’t cache the micromamba binary. Doing that for 5MB is either way not really necessary; downloading it directly is probably even faster 😅
Actually one of the reasons to cache the binary was because of spurious conda-forge download failures. I guess that problem is gone now that we download from GitHub :)