Skip to content

Build and test conda-recipe-cf for Intel Python CI - #294

Open
jharlow-intel wants to merge 1 commit into
mainfrom
ci/intel-python-ci
Open

jharlow-intel wants to merge 1 commit into
mainfrom
ci/intel-python-ci

Conversation

@jharlow-intel

@jharlow-intel jharlow-intel commented Oct 23, 2026 •

Copy link
Copy Markdown
Collaborator

Description

Adds what Intel Python CI (gh-ci) needs from mkl_umath: a ci/ directory and a new workflow, .github/workflows/intel-ci.yml. The workflow builds conda-recipe-cf for every platform and Python version the recipe declares, and tests each package in a clean conda-forge environment with ci/test.py. Intel's Jenkins then waits for that run, tests each package again on its own machines, scans it, and for a release tag publishes the packages it tested. Jenkins isn't switched on for mkl_umath yet, so until it is, this only adds a GitHub Actions workflow.

  • ci/matrix.py, ci/build.py, ci/hooks.py: the shared gh-ci scripts, standard library only. Here they look for conda-recipe-cf/ first and build Linux and Windows on GitHub-hosted runners. hooks.py installs the test requirements from ci/config.yml, the way Jenkins does.
  • ci/test.py: runs pytest --pyargs mkl_umath against the installed package and writes a JUnit report.
  • ci/benchmark.py: because benchmarks/ exists, Jenkins runs it once per pull request or tag, with the newest regular Linux package, on a bare-metal benchmarking machine. It runs the asv suite against the installed package: one quick sample of each benchmark on a pull request, a full measurement on a tag. A failing benchmark fails it; nothing compares the timings with a baseline yet.
  • ci/config.yml: the workflow, the artifact names (mkl_umath {platform} Python {python}, as conda-package-cf.yml names them) and the test requirements, pytest, and the benchmark requirements, psutil, with asv from PyPI, as conda-forge has no asv for Python 3.15 yet.
  • conda-recipe-cf/conda_build_config.yaml: now lists the Python versions, the ones conda-package-cf.yml builds today, for ci/matrix.py, and numpy: '2'. Without a NumPy variant, conda-build falls back to NumPy 1.26, which has no builds for Python 3.13 and newer. It also replaces the numpy: '1.26.4' pin, which the NumPy 2-only code since Require NumPy >= 2 and remove the NumPy 1 code paths #289 can no longer build against. conda-package-cf.yml passes --python and --numpy itself, so it is unaffected.
  • ci/README.md and AGENTS.md notes.

A pull request builds the oldest and the newest regular Python versions on Linux and Windows; pushes to main and tags build them all.

Miniforge is pinned to 26.7.2-0. Miniforge 26.9.4-0, released on 22 October, makes setup-miniconda's conda init fail on Windows runners, and the existing conda-package*.yml workflows, which install latest, hit it too on this pull request.

Merged with main after #287 and #283. conda_build_config.yaml keeps main's numpy: '2' and compilers, with the python: list above them; main's cf workflow still builds 3.10 to 3.15 and 3.14t, so the list is unchanged.

Overlap with #287 (now merged). It also sets numpy: '2' in conda_build_config.yaml and drops Python 3.10, so whichever lands second needs a small rebase, and if 3.10 goes it should leave the python: list here too. conda-package-cf.yml and intel-ci.yml now both build conda-recipe-cf; retiring one can be a follow-up.

Verification

  • Tests: this pull request's Intel Python CI run built Linux and Windows for Python 3.10 and 3.15, the oldest and the newest, and ran ci/test.py against each package: 392 passed on each platform and version, the whole installed suite.
  • Lint: pre-commit run on every changed file, all hooks passing, and zizmor on intel-ci.yml, no findings.
  • python ci/matrix.py lists 14 builds, Linux and Windows for 3.10 to 3.15 and 3.14t; with --event pull_request it lists 3.10 and 3.15 on both.
  • ci/config.yml loads with gh-ci's own parser.

Not verified

  • The builds a tag or a push to the default branch adds, Python 3.11 to 3.14 and 3.14t; they use the same jobs.
  • The Jenkins side, which isn't enabled for mkl_umath yet, the benchmark cell included.
  • ci/benchmark.py against mkl_umath's suite. The same script ran mkl_fft's.

Adds what Intel Python CI (gh-ci) needs: a ci/ directory and
.github/workflows/intel-ci.yml. The workflow builds conda-recipe-cf with
conda-build and the wheels with cibuildwheel, for every platform and Python
version the recipe and pyproject.toml declare, and tests each package in a
clean environment with ci/test.py. Intel's Jenkins tests them again, scans
them, runs ci/benchmark.py on the newest Linux package, and publishes a
release tag's tested packages as its GitHub Release.

conda-recipe-cf/ is now the only recipe: conda-recipe/ and conda-package.yml,
which built it against Intel's channel and copied wheels out through
WHEELS_OUTPUT_FOLDER, are removed. conda-package-cf.yml reports the same check
names, so the required checks still run. conda_build_config.yaml now lists the
Python versions.

The wheels link MKL's layers and the Intel OpenMP runtime, so their run-time
requirements on mkl and intel-openmp come from [tool.gh-ci] wheel-requires in
pyproject.toml, which ci/build.py adds to each wheel: in [project] they would
fail the recipe's pip check, as conda-forge's mkl has no pip metadata.
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