Caching troubles & questions

I’m trying to take advantage of caching of dependencies. It seems like whatever I do thesetup-miniconda action takes just as long regardless of whether I’ve cached my dependencies or not.

    - name: Cache conda
      uses: actions/cache@v1
      env:
        # Increase this value to reset cache if environment.yml has not changed
        CACHE_NUMBER: 5
      with:
        path: ~/conda_pkgs_dir
        key: ${{ runner.os }}-conda-${{ env.CACHE_NUMBER }}-${{ hashFiles('environment.yml') }}
    - uses: goanpeca/setup-miniconda@v1
      with:
        activate-environment: myenvname
        channel-priority: strict
        environment-file: environment.yml
        use-only-tar-bz2: true # IMPORTANT: This needs to be set for caching to work properly!

Have I made a mistake here that is preventing setup-miniconda from loading the packages from ~/conda_pkgs_dir as specified in the docs?

Important note Possibly worth documenting, removing python-version: 3.7 from the step resulted in a faster build, but still no advantage when caching. I was seeing much slower build times as the step would hang on installing python 3.7.

My environment file looks a bit like this:

name: myenvname
channels:
  - pytorch
  - anaconda
  - conda-forge
  - defaults
dependencies:
  - python=3.7
  - jupyter=1.0.0
  - numpy=1.17.4
  - pandas=0.25.3
  - pytorch=1.4.0
  - pip=20.0.2
  - pip:
    - coverage==5.0.3

It seems like some dependencies are downloading regardless of the fact that they were stored in the cache (the caching step is successful and it shows a reasonable size).

# Updating conda environment from yaml file...
##############################################

/usr/share/miniconda/condabin/conda env update --file environment.yml --name myenvname
Collecting package metadata (repodata.json): ...working... done
Solving environment: ...working... done
Preparing transaction: ...working... done
Verifying transaction: ...working... done
Executing transaction: ...working... done
Ran pip subprocess with arguments:
['/usr/share/miniconda/envs/my-org/bin/python', '-m', 'pip', 'install', '-U', '-r', '/home/runner/work/my-org/my-repo/condaenv.p1divyve.requirements.txt']
Pip subprocess output:
Collecting coverage==5.0.3
  Downloading coverage-5.0.3-cp37-cp37m-manylinux1_x86_64.whl (227 kB)

It seems like it’s not picking up the files that were restored from the cache, what am I missing? Also should the updated cache@v2 be supported?

[MGough]

Thanks again for the suggestion, it helped send me in the right direction for tidying up the file. I can hopefully make some small README suggestions in the next few days.

For anyone else that stumbles upon this: Currently I’ve found that the caching doesn’t save much time, likely due to the solving of a large number of packages (there are more than in the example I provided) taking a long period of time. I plan on reducing the number of packages, a lot of the python ML packages have some questionable dependency decisions, but for now I found that running mamba with strict channel priority and no caching is the fastest option.

[goanpeca]

No problem 😃 , please share any ideas on how to improve the README to make things clearer!