Skip to content

Drop the conda package cache from the conda CI workflows - #262

Open
antonwolfy wants to merge 1 commit into
masterfrom
drop-conda-ci-cache
Open

antonwolfy wants to merge 1 commit into
masterfrom
drop-conda-ci-cache

Conversation

@antonwolfy

@antonwolfy antonwolfy commented Oct 28, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

The Cache conda packages steps in conda-build-test.yml make the conda workflows slower and save nothing. In today's runs they took 11-13 of ~97 runner-minutes per conda-package.yml run and 33 of ~197 per conda-package-cf.yml run (12-17%), mostly on macOS. No step got faster in return.

Measured on 158 successful jobs from 4 runs on 2026-10-28: master 40669276700 / 40669276773 and PR 40669327541 / 40669327527.

Linux Windows macOS
Build jobs: restores that found a cache 0 / 32 0 / 32 0 / 16
Build jobs: time to save the cache 10 s 13 s 42 s
Test jobs: cache restore + save 31 s 33 s 120 s
Test jobs: Install mkl-service when its packages were in the cache 9 s 19 s 21 s
Test jobs: Install mkl-service when it downloaded 120-190 MB 9 s 19 s –

Why it doesn't help:

  • Entries are evicted before they are reused. Each entry is ~1 GB, because the package directory holds both the .conda archives and their unpacked copies. Each run saves about sixty of them. The repo's cache store held 20 entries (20.6 GB), only macOS ones from the latest run, so the build key (meta.yaml hash) never gets an exact hit.
  • Test jobs restore the wrong entry. They never hit their own lockfile key. The restore-keys prefix picks up the build job's package directory saved minutes earlier, and the <os>-conda-0- fallback gave 3 of the 8 macOS test jobs the Python 3.13 entry.
  • conda-package.yml and conda-package-cf.yml use the same keys. 28 saves failed on the collision, and about half the test jobs restored the other channel's packages and downloaded everything anyway.
  • Downloads are not the bottleneck. Fetching the packages from conda-forge and the Intel channel takes about as long as reading them from a local cache.

Changes

  • conda-build-test.yml: remove both Cache conda packages steps, the Collect dependencies step (its dry-run lockfile was only used for the cache key; Install mkl-service prints the same plan), the CONDA_PKGS_DIRS env and the pkgs-dir input
  • conda-package.yml, conda-package-cf.yml: stop passing pkgs-dir
  • .github/AGENTS.md: replace the cache-key note with why the conda jobs don't cache packages

Job and check names are unchanged. The existing cache entries are deleted automatically after 7 days without use.

Test plan

  • pre-commit (including actionlint) passes on the changed files
  • zizmor --min-severity medium .github/ reports no findings
  • Conda package using Intel and Conda package using conda-forge are green on this PR (all 80 conda jobs; build-with-clang fails on the apt-key issue already on master, fixed by Replace apt-key in IntelLLVM clang workflow #261)

The actions/cache steps in conda-build-test.yml cost 12-17% of the
runner time of a conda-package or conda-package-cf run without making
any step faster:

- Build jobs never restored a cache: each run saves about sixty ~1 GB
  entries, so the previous run's entries are evicted before the next
  run starts.
- Test jobs only restored the build job's package directory through
  the restore-keys prefix, and the Intel and conda-forge workflows
  shared the same keys, so about half of them got the other channel's
  packages and downloaded everything anyway.
- The install step took the same time whether its 120-190 MB of
  packages came from the cache or from the channels.

Remove both cache steps, the lockfile-only "Collect dependencies"
step, CONDA_PKGS_DIRS and the pkgs-dir input, and replace the cache
key note in .github/AGENTS.md.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant