Repository navigation
Build and test conda packages and wheels - #204
jharlow-intel wants to merge 2 commits into
Conversation
|
|
||
| concurrency: | ||
| group: intel-ci-${{ github.ref }} | ||
| cancel-in-progress: true |
There was a problem hiding this comment.
With cancel-in-progress: true keyed on github.ref, two quick merges cancel the first commit's whole run. Jenkins, which waits for that run, gets no packages for it.
| cancel-in-progress: true | |
| cancel-in-progress: ${{ github.event_name == 'pull_request' }} |
There was a problem hiding this comment.
Applied in 6006c16, so a push to master no longer stops the run before it. Every tag is its own ref, so tag runs never cancelled each other either.
| numpy: | ||
| - '2' |
There was a problem hiding this comment.
Agreed, this should land after #202. With the current pin_compatible('numpy', min_pin="x.x"), the 3.15 package built here requires numpy >=2.5,<3.0a0 at run time, which #202 fixes. Once #202 merges I will rebase: numpy: '2' will come from #202, and 3.10 will leave the python: list along with its matrix.
| @@ -1,3 +1,16 @@ | |||
| # The Python versions to build, one per line and without selectors: ci/matrix.py | |||
| # reads them for .github/workflows/intel-ci.yml. NumPy 2, as in conda-forge's | |||
| # global pinning; conda-package-cf.yml passes its own with --python and --numpy. | |||
| "--artifacts", required=True, type=Path, help="the downloaded artifact" | ||
| ) | ||
| parser.add_argument( | ||
| "--work", required=True, type=Path, help="an empty scratch directory" |
There was a problem hiding this comment.
hooks.py doesn't check that --work is empty, and may install conda-index into the user's base environment.
There was a problem hiding this comment.
Fixed in b758764. hooks.py now refuses a --work that is not an empty directory, and it writes the local channel's repodata.json itself, so it installs nothing into base.
|
|
||
| - uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0 | ||
| with: | ||
| python-version: "3.12" |
There was a problem hiding this comment.
Is there any issue to use the newer python?
There was a problem hiding this comment.
No issue: the job only runs ci/matrix.py, which needs nothing beyond the standard library. Moved to 3.14 in 6006c16.
| activate-environment: "" | ||
| conda-remove-defaults: "true" | ||
|
|
||
| - uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0 |
There was a problem hiding this comment.
Alternatively we can drop setup-python and run with shell: bash -el {0} with base activated.
bash is available on Windows runners too, and setup-miniconda supports this shell there. The step bodies become plain python ci/build.py … and python ci/hooks.py …. The $CONDA path code and hooks.py's re-run of itself would then only matter for local use.
There was a problem hiding this comment.
Done in 6006c16: build and test run in bash -el {0} with base active, without setup-python. On Windows the new steps work: conda-build installs, the package builds and the imports pass. This run is still red on Windows because conda-forge's pytest 9.2.0, published today, dropped colorama again, so the recipe's pip check fails (conda-forge/pytest-feedstock#208). I will re-run once a fixed build is out.
There was a problem hiding this comment.
Re-ran after conda-forge published the fixed pytest build: the run is green on Linux and Windows, test jobs included.
| @@ -0,0 +1,135 @@ | |||
| # Intel Python CI (gh-ci) for mkl_random: builds the conda-forge recipe, conda-recipe-cf, for every | |||
There was a problem hiding this comment.
The same PR is open in three repos at once.
Have you considered moving common things (scripts, workflow) to some common repo like https://github.com/IntelPython/devops-tools ?
That would help to reduce the duplication.
There was a problem hiding this comment.
Yes, we considered it. Duplicated code is a known consequence of the new CI's design, where each repository carries everything its CI needs, and the design's other benefits make up for it.
Build and test steps run in a bash login shell with conda base active, so they call ci/build.py and ci/hooks.py directly and need no setup-python. Pushes to the default branch no longer cancel each other. Same as IntelPython/mkl_random#204.
Build and test steps run in a bash login shell with conda base active, so they call ci/build.py and ci/hooks.py directly and need no setup-python. Pushes to the default branch no longer cancel each other. Same as IntelPython/mkl_random#204.
2ecff7b to
8b5d74a
Compare
vchamarthi
left a comment
There was a problem hiding this comment.
Went through this on the branch. The PR description looks stale: conda-recipe-cf is deleted, macOS and the wheels are built too, and Jenkins is enabled in dry run. There are also no AGENTS.md notes in the diff. Also, conda-package.yml is deleted, so the Intel channel build is no longer tested anywhere. Details inline.
| - wheel >=0.41.3 | ||
| run: | ||
| - python | ||
| - {{ pin_compatible('numpy', min_pin="x.x", max_pin="x") }} |
There was a problem hiding this comment.
pin_compatible('numpy', min_pin="x.x", max_pin="x") resolves to >=2.2,<3.0a0 / >=2.5,<3.0a0 in the build logs, depending on the build. That excludes numpy 2.0 to 2.4 at runtime for the first one, and the minimum follows whatever numpy was in the host env. Is that the intent? A fixed lower bound like the old >=1.26.4 would be easier to reason about.
|
|
||
| test: | ||
| name: Test ${{ matrix.name }} Python ${{ matrix.python }} | ||
| needs: [matrix, build] |
There was a problem hiding this comment.
needs: [matrix, build] means a macOS conda failure skips test and so blocks the release, same for the wheel job at :155. If macOS is meant to gate releases that is fine, just checking it is on purpose.
| # macOS runs on Intel runners, as MKL has no Apple silicon build; Jenkins ignores it. | ||
| build: | ||
| name: ${{ matrix.name }} Python ${{ matrix.python }} | ||
| needs: matrix |
There was a problem hiding this comment.
This builds conda-recipe on every push and PR, and I don't see conda-package-cf.yml removed, so the same package may be built twice. Worth deleting or limiting the old workflow if it is now redundant.
| """ | ||
| Intel Python CI (gh-ci) test for mkl_random. | ||
|
|
||
| GitHub Actions, through ci/hooks.py, and Intel's Jenkins both run this with one |
There was a problem hiding this comment.
Nit: the docstring says the test runs against a conda package, but the wheel job uses it too. Might be worth saying so.
Adds a ci/ directory and .github/workflows/intel-ci.yml. The workflow builds conda-recipe/ 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. 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 reports the same check names. conda_build_config.yaml now lists the Python versions, and numpy: '2', as conda-build otherwise defaults to 1.26. The wheels' run-time requirement on mkl comes from [tool.gh-ci] wheel-requires in pyproject.toml, which ci/build.py adds to each wheel: in [project] it would fail the recipe's pip check, as conda-forge's mkl has no pip metadata. The wheels build against mkl-devel >=2026.2,<2027, the range they require at run time, and the Linux wheels are tagged manylinux_2_28 only, like the mkl wheel. ci/build.py keeps only the $ORIGIN entries of each ELF file's RPATH and RUNPATH in a wheel, as meson-python keeps the isolated build env's absolute lib directory, and refuses a file that would be left with none. ci/hooks.py tests each wheel in a venv made from conda-forge's Python, as pip users install it. Every python: entry in conda_build_config.yaml names its ABI, which ci/matrix.py requires, and every push and tag run gets a concurrency group of its own.
754b382 to
f881d71
Compare
conda-build reads x86 as any x86 CPU and has no osx64 selector, while rattler-build has x86 for 32-bit only and osx64 for Intel macOS, so ci/matrix.py now gives conda-build its own values for both and refuses a conda-build skip that uses osx64. ci/build.py keeps a search path entry only when it is $ORIGIN or a directory under it, names RPATH and RUNPATH entries apart, and rewrites the wheels in scratch, so a refused wheel never reaches --output.
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 wasconda-recipe-cf/. The Intel-channel recipe andconda-package.ymlare removed;conda-package-cf.ymlbuildsconda-recipe/and keeps its check names.python:list inconda_build_config.yaml, which also setsnumpy: '2', as conda-build otherwise falls back to NumPy 1.26. The wheels follow thepyproject.tomlclassifiers: 3.10 to 3.15 plus 3.14t and 3.15t.mkl >=2026.2,<2027through[tool.gh-ci] wheel-requires, whichci/build.pyadds to each wheel.meson.buildaddsLibraryto CMake's search path on Windows, where mkl-devel puts its CMake config.ci/test.pyrunspytest --pyargs mkl_randomon the installed package. The tests'hashlib.md5calls passusedforsecurity=False.ci/benchmark.pyruns the asv suite inbenchmarks/against the installed package: one quick sample of each benchmark on a pull request, a full measurement on a tag.Miniforge is pinned to 26.7.2-0, as 26.9.4-0 makes
setup-miniconda'sconda initfail on Windows runners.Overlap with #202. It changes
conda-recipe-cf/, which this moves toconda-recipe/, so whichever lands second needs a rebase.Validation: run 42099114121 built and tested the conda packages for 3.10 and 3.15 on Linux, Windows and macOS, and the wheels for 3.10 and 3.15 on Linux and Windows; all 21 jobs passed. Not run yet: the full matrix, which only
masterand tags build.