Repository navigation
ci: align conda-forge workflow with the feedstock build - #398
Open
antonwolfy wants to merge 2 commits into
Open
antonwolfy wants to merge 2 commits into
antonwolfy wants to merge 2 commits into
Conversation
Make conda-package-cf.yml build and test the recipe the way conda-forge/mkl_fft-feedstock does, so issues show up here before a feedstock PR: - Pin numpy to '2' in conda_build_config.yaml, like conda-forge pinning, so each Python builds against the newest NumPy 2.x instead of hard-coded 2.2/2.3/2.5 rows. The --numpy CLI flag is dropped because conda-build turns "2" into an invalid "2." spec. - Rely on numpy run_exports instead of a bare numpy run requirement, as the feedstock recipe does since 2.4.0. - Stop passing --no-test, so the recipe test section (pip check, imports, pytest) runs as in the feedstock. - Use gcc 15 and sysroot 2.17 on Linux, as conda-forge pinning does, and drop the unused cxx_compiler entries. - Build on windows-2022 to get Visual Studio 2022, as the feedstock does, instead of windows-latest which now ships Visual Studio 2026. - Drop Python 3.10, which conda-forge no longer builds. - Point the Windows cache steps at ~/conda_pkgs_dir, the package directory setup-miniconda configures; /home/runner/conda_pkgs_dir does not exist on Windows, so nothing was cached.
- Point the Windows cache steps in conda-package.yml at ~/conda_pkgs_dir, the package directory setup-miniconda configures. /home/runner/conda_pkgs_dir does not exist on Windows, so the build and test caches were never saved or restored. - Add a "cf" segment to the cache keys and restore-keys in conda-package-cf.yml. Both workflows used the same "<os>-conda-<n>-python-<ver>-<hash>" keys with the same path, so their build jobs hit each other's caches by exact key and neither saved its own packages, and restore-keys prefixes matched across workflows too. The fixed Windows paths would have collided the same way.
antonwolfy
requested review from
jharlow-intel,
ndgrigorian,
vlad-perevezentsev and
xaleryb
as code owners
October 20, 2026 16:12
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
conda-package-cf.ymlis meant to catch conda-forge problems before a feedstock PR does, but it built and testedconda-recipe-cfdifferently from conda-forge/mkl_fft-feedstock. This PR closes the gaps found by comparing the two: the feedstock's latest CI run (2.4.0, build 1) against the latestconda-package-cf.ymlrun on master.Commit 1: align the build with the feedstock
numpy: '2'): 2.4.6 on 3.11, 2.5.4 on 3.12+numpy: '2'inconda_build_config.yamlnumpytest:section (pip check, imports, pytest)--no-test)windows-2022(VS 2022)windows-latest, nowwindows-2025-vs2026(VS 2026)windows-2022Notes:
--numpy 2can't be used. conda-build's legacy CLI handling expands dotless versions (27→2.7), so2becomes2.and the solver rejects it. The pin therefore lives inconda_build_config.yaml, the way the feedstock sets it, and the per-rownumpymatrix values are gone. Build job names lose the NumPy part, e.g.build_linux (3.11); none of them is a required check.cxx_compiler*entries were unused, since the recipe has no C++ compiler. They had been copied from the Intel-channel recipe config.conda-package.yml,build_pip.ymland the clang workflows.Commit 2: fix the conda package caches
/home/runner/conda_pkgs_dir, which doesn't exist on Windows. setup-miniconda usesC:\Users\runneradmin\conda_pkgs_dir, so nothing was ever saved or restored. They now cache~/conda_pkgs_dir.conda-package.ymlandconda-package-cf.ymlused identical cache keys with the same path. On master, thebuild_linux3.15 jobs of both workflows hitLinux-conda-0-python-3.15-6aee6ded…by exact key, so neither saved its own packages, and the restore-keys prefixes matched across workflows too. Keys inconda-package-cf.ymlnow have acfsegment.The first run after merge will miss the cache for the conda-forge jobs and all Windows jobs and create new entries, about 2.5–3 GB each judging by the current Linux entries.
Not addressed here
defaultsvia the runner's preinstalled miniconda; the feedstock uses conda-forge only.Checklist
mkl_fft/tests/; bug fixes have a regression test.CHANGELOG.mdupdated under## [dev]with a[gh-NNN]link, or the change isn't user-visible.