Open sp-ricard-valverde opened 3 years ago
Also, it seems that tool-cache
is looking for a SemVer compliant version string when restoring the caché, and recent Miniconda3 versions are in the form py37_*
, py38_*
, py39_*
, latest
so they won't ever be restored:
https://github.com/actions/toolkit/blob/2f164000dcd42fb08287824a3bc3030dbed33687/packages/tool-cache/src/tool-cache.ts#L514
Just came across this, as I observed the following cache miss repeatedly happening in the logs:
Will fetch Mambaforge 4.11.0-4 from https://github.com/conda-forge/miniforge/releases/download/4.11.0-4/Mambaforge-4.11.0-4-Linux-x86_64.sh
Ensuring Installer...
Checking for cached Mambaforge@4.11.0-4...
Did not find Mambaforge-4.11.0-4-Linux-x86_64.sh 4.11.0-4 in cache
Downloaded Mambaforge-4.11.0-4-Linux-x86_64.sh, ensuring extension .sh
Caching Mambaforge@4.11.0-4...
Cached Mambaforge@4.11.0-4: /opt/hostedtoolcache/Mambaforge/4.11.0-4/x86_64!
With this action configuration:
- name: Setup Mambaforge
uses: conda-incubator/setup-miniconda@v2
with:
miniforge-version: 4.11.0-4
miniforge-variant: Mambaforge
use-mamba: true
auto-update-conda: false
https://github.com/conda-incubator/setup-miniconda/blob/723ab12c1d66bb893c5ac701f8e387f00b24549e/src/installer/base.ts#L49-L52
Given for instance
miniconda-version: latest
this makes https://github.com/actions/toolkit/blob/2f164000dcd42fb08287824a3bc3030dbed33687/packages/tool-cache/src/tool-cache.ts#L472-L476 to look for a path in the tool cache like<toolcachedir>/Miniconda3-latest-Linux-x86_64.sh/latest/x86_64
instead of<toolcachedir>/Miniconda3/latest/x86_64
, where it's actually being saved.