[jharlow-intel]

Adds ci/ and .github/workflows/intel-ci.yml, which build the conda packages for Linux, Windows and Intel macOS and the wheels for Linux and Windows, on every declared Python, and test each in a clean environment.

• conda-recipe/ is now the only recipe: the conda-forge one that was conda-recipe-cf/. The Intel-channel recipe and conda-package.yml are removed; conda-package-cf.yml stays and keeps its check names. No workflow in this repository builds or tests against the Intel channel any more: conda-package-cf.yml and intel-ci.yml both use conda-forge only.
• The conda packages and the wheels build Python 3.11 to 3.15 plus 3.14t and 3.15t: the conda list follows the feedstock, plus 3.15t, and the wheels follow the pyproject.toml classifiers, which drop 3.10 here. requires-python still allows 3.10.
• Wheels build with cibuildwheel, with MSVC on Windows, and leave MKL out. They require mkl from the mkl-devel version the build used up to its next major, through [tool.gh-ci] pin-compatible, which ci/build.py stamps into each wheel. ci/build.py also keeps only the $ORIGIN RPATH and RUNPATH entries of the wheels' ELF files, dropping the isolated build env's absolute path. The Linux wheels are tagged manylinux_2_28, like the mkl wheel.
• meson.build adds Library to CMake's search path on Windows, where mkl-devel puts its CMake config.
• ci/test.py runs pytest --pyargs mkl on the installed package: a conda package in a conda-forge environment, a wheel in a venv made from conda-forge's Python, so mkl/_init_helper.py is what loads MKL on Windows.

Validation: run 42277684124 built and tested the conda packages for 3.11 and 3.15 on Linux, Windows and macOS, and the wheels for 3.11 and 3.15 on Linux and Windows. Not run yet: the full matrix, which only master and tags build.

[Copilot]

🔵 Needs a closer look

The native-package pipeline requires end-to-end Linux/Windows CI validation of conda solving and runtime loading for 3.14t/3.15t, which remain unverified by standard-library-only checks.

No open issues 🎉

What changed in this PR

Adds GitHub Actions build and package testing for Intel Python CI, preparing mkl-service for Jenkins integration. Jenkins is not yet enabled for this repository.

Changes:

• Derives Linux and Windows build matrices from the conda-forge recipe, selecting four builds for pull requests and all 16 for master pushes and tags.
• Adds build and isolated package-test scripts, with pytest results written as JUnit reports.
• Documents the integration and its configuration.

File	Description
conda-recipe-cf/​conda_build_config.yaml	Declares Python versions and ABI variants for matrix generation.
ci/​test.py	Checks the interpreter and runs installed-package tests with JUnit output.
ci/​README.md	Documents CI operation and local commands.
ci/​matrix.py	Generates platform and Python matrices from build declarations.
ci/​hooks.py	Installs artifacts into clean environments and runs package tests.
ci/​config.yml	Defines the workflow, artifact naming, and test requirements.
ci/​build.py	Builds packages for a selected Python variant and collects artifacts.
AGENTS.md	Adds a pointer to Intel Python CI documentation.
.github/​workflows/​intel-ci.yml	Orchestrates matrix generation, builds, artifact uploads, and tests.
.github/​AGENTS.md	Documents the workflow and its recipe-derived matrix exception.

_{Review effort: Balanced}

[vchamarthi]

Gh-ci side looks good to me. Scripts match the other three repos, artifact names line up with ci/config.yml, actions are pinned.

The PR description is out of date though. It says the workflow builds conda-recipe-cf (deleted now), Linux and Windows only (macOS and wheels are built too), and that Jenkins isn't on for mkl-service (it's enabled in config/gh-ci.json, dry run). It also doesn't say conda-package.yml and the Intel-channel build are gone, which is the part reviewers need to see. Rest are inline.

[jharlow-intel]

Thanks @vchamarthi, I've rewritten the description and the title to match what the PR does now.

[vchamarthi]

LGTM 🚀

[vchamarthi]

Looks Great!

[antonwolfy]

A few points inline, none of them blocking. One more for the description: with conda-package.yml and the Intel-channel recipe removed, no public workflow builds or tests against the Intel channel any more (intel-ci.yml uses conda-forge only too). Worth saying that outright.

[antonwolfy]

Re-reviewed the latest push: everything from my last round except the dev upload is addressed, and I resolved those threads. A few small points inline, none of them blocking.

[Copilot]

🔵 Needs a closer look

The native-wheel pipeline’s ELF and loader changes still need build-and-runtime validation for free-threaded 3.14t/3.15t ABIs, as the cited run covers only regular Python 3.11/3.15.

No open issues 🎉

_{Review effort: Balanced}

[antonwolfy]

The Linux wheels build without hardening flags. I compared the py3.11 Linux wheel from this PR's Intel CI run with the 2.9.0 one from the internal Jenkins build. The Jenkins wheel came out of the conda build, so conda-forge's gcc gave it -fstack-protector-strong and -Wl,-z,relro -Wl,-z,now: its .so files have __stack_chk_fail and BIND_NOW. The new wheel is built by the manylinux image's gcc 14 with no flags set, and has neither: no stack protector, and only partial RELRO.

The conda packages don't need anything, as conda-forge's compiler activation already sets these. The Linux build log shows CFLAGS=... -fstack-protector-strong ..., CPPFLAGS=... -D_FORTIFY_SOURCE=2 ... and LDFLAGS=... -Wl,-z,relro -Wl,-z,now ..., and the new conda .so files have both. Windows is fine too: with MSVC's defaults the .pyd files have the same characteristics as the Jenkins ones (dynamic base, high-entropy VA, NX compat).

Could we pass the same subset to the wheel build? Something like this, which I haven't run through cibuildwheel:

Suggested change

	[tool.cibuildwheel.linux]
	[tool.cibuildwheel.linux]
	# The hardening flags conda-forge's compilers set for the conda packages
	environment = { CFLAGS = "-fstack-protector-strong", CPPFLAGS = "-D_FORTIFY_SOURCE=2", LDFLAGS = "-Wl,-z,relro -Wl,-z,now" }

[jharlow-intel]

Thanks, confirmed: the 3.11 wheel from run 42277684124 had partial RELRO, no __stack_chk_fail and no fortified calls, while the conda package from the same run has all three. The flags are in as suggested, and ci/build.py now refuses a wheel with an ELF file that lacks full RELRO (GNU_RELRO plus BIND_NOW), so they can't silently stop applying. The stack protector has no per-file check, as a library without arrays legitimately has no canary. Run 42291879334 built the wheels with them: every .so in the 3.11, 3.15 and 3.15t Linux wheels has full RELRO and __stack_chk_fail, and _mklinit has fortified calls, as in the conda package.

[antonwolfy]

More a question than a request: do we need the conda packages to record their source commit, to stay aligned with the ones the internal Jenkins build makes?

Jenkins calls conda build ... --extra-meta remote_url=https://github.com/IntelPython/mkl-service sha=<commit>, so the 2.9.0 packages have this in info/about.json:

"extra": {"...": "...", "remote_url": "https://github.com/IntelPython/mkl-service", "sha": "6cc5780b3359482b47b5663dfe91a33048117213"}

The packages built here have only recipe-maintainers there, and their info/git is empty, as the recipe builds from a local path. So a package alone no longer says which commit it came from. 2.10.0dev0 with build number 37 means 37 commits after the tag, which doesn't pin one commit across branches. For a tag build the tag identifies it, and the wheels never recorded a commit, from Jenkins or from here.

If something downstream reads that sha, it would be a small addition here, only when the variables are set so local runs keep working:

"--extra-meta",
f"remote_url={os.environ['GITHUB_SERVER_URL']}/{os.environ['GITHUB_REPOSITORY']}",
f"sha={os.environ['GITHUB_SHA']}",

If nothing does, leaving it out is fine with me.

[jharlow-intel]

Added: when GITHUB_SERVER_URL, GITHUB_REPOSITORY and GITHUB_SHA are set, conda-build gets --extra-meta remote_url=<server>/<repo> sha=<GITHUB_SHA>, and local runs are unchanged. On a pull request GITHUB_SHA is the merge commit the job checked out, which is what the package is built from. The packages from run 42291879334 have both in info/about.json.

[antonwolfy]

A pull request builds no free-threaded package in this workflow: for_event keeps only the regular versions, so this PR's runs built 3.11 and 3.15, and 3.14t and 3.15t first build on a push to master or a tag.

For the conda packages the other workflows cover it: conda-package-cf.yml builds and tests 3.14t and 3.15t from the same recipe on every PR, on Linux, Windows and macOS, and build_pip.yml and the two Clang workflows build them from source on Linux. What no PR builds is the free-threaded wheels: cibuildwheel's cp314t and cp315t in the manylinux container and with MSVC on Windows, and their test in a venv with mkl from PyPI. All of this workflow's runs so far were pull requests, so no free-threaded wheel has been built yet, and on Windows the only free-threaded build a PR runs is the conda one.

Could a pull request also build the newest free-threaded version? With this, a PR gets 3.11, 3.15 and 3.15t on each platform, which adds two wheel builds and two wheel tests, plus three conda legs. I checked it with matrix.py --event pull_request, with and without --system wheel, but not in Actions:

Suggested change

	"""All of them, or for a pull request the oldest and newest regular ones."""
	if event not in PULL_REQUEST_EVENTS:
	return pythons
	regular = [python for python in pythons if not python.version.endswith("t")]
	regular = regular or pythons
	return list(dict.fromkeys(regular[:1] + regular[-1:]))
	"""
	All of them, or for a pull request the oldest and newest regular ones and
	the newest free-threaded one.
	"""
	if event not in PULL_REQUEST_EVENTS:
	return pythons
	regular = [python for python in pythons if not python.version.endswith("t")]
	threaded = [python for python in pythons if python.version.endswith("t")]
	regular = regular or pythons
	return list(dict.fromkeys(regular[:1] + regular[-1:] + threaded[-1:]))

ci/README.md would need the same in "A pull request into master". If matrix.py should stay the same as in the other repos that use it, a workflow_dispatch: trigger would at least let the full matrix run before a merge.

[jharlow-intel]

Done as suggested, and ci/README.md says so: a pull request now builds 3.11, 3.15 and 3.15t. Run 42291879334 built and tested the cp315t wheels on Linux and Windows, along with the 3.15t conda packages on all three platforms.

[antonwolfy]

Nit: eol comes from the whole file, so a METADATA whose headers use LF but whose description has CRLF, such as a README checked out with CRLF and copied as it is, gets eol = "\r\n". Then partition("\r\n\r\n") finds no blank line, and the Requires-Dist line goes at the end of the description:

>>> with_requirements(b"Metadata-Version: 2.1\nName: mkl-service\n\n# README\r\ntext\r\n", ["mkl >=2026.2.0,<2027"])
b'Metadata-Version: 2.1\nName: mkl-service\n\n# README\r\ntext\r\nRequires-Dist: mkl >=2026.2.0,<2027\r\n'

The build still logs build: added Requires-Dist ..., and pip installs that wheel without mkl, so the first sign would be the wheel test failing to load MKL. meson-python writes the description with LF today (the Windows wheels' METADATA has no CRLF), so nothing hits it now.

Taking the line ending from the headers alone fixes it, and gives the same output as now for LF, for CRLF, and for CRLF headers with an LF description, with or without one:

Suggested change

	# Some Windows build backends write the metadata with CRLF.
	eol = "\r\n" if "\r\n" in text else "\n"
	# Some Windows build backends write the metadata with CRLF. Take the line
	# ending from the headers, as the description can keep the README's.
	headers = re.split(r"\r?\n\r?\n", text, maxsplit=1)[0]
	eol = "\r\n" if "\r\n" in headers else "\n"

[antonwolfy]

Nit: intel-ci.yml runs on every pull request, as its pull_request: trigger has no branches: filter, like the other workflows here. So a pull request into another branch gets the same reduced matrix.

Suggested change

	**A pull request into `master`.** Actions builds the oldest and the newest regular Python versions on Linux, Windows and macOS, as a conda package and, where `pyproject.toml` declares the platform, as a wheel, and tests each package.
	**A pull request.** Actions builds the oldest and the newest regular Python versions on Linux, Windows and macOS, as a conda package and, where `pyproject.toml` declares the platform, as a wheel, and tests each package.

[antonwolfy]

Nit: the expression gives 3 days to every run that isn't a tag, so packages from pushes to master are kept 3 days too, not only the pull requests' ones. The wheel upload below uses the same expression.

Suggested change

	# Pull requests keep them 3 days, tags 30.
	# Tags keep them 30 days, pull requests and pushes to master 3.