Repository navigation
Build and test conda-recipe-cf for Intel Python CI - #204
jharlow-intel wants to merge 1 commit 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. For what it is worth, Jenkins only waits for pull request and tag runs, and every tag is its own ref, so it never lost packages this way.
| 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, as Jenkins does, 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.
8cda0c8 to
354eaf5
Compare
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, 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.
354eaf5 to
2655f3f
Compare
Description
Adds what Intel Python CI (gh-ci) needs from mkl_random: a
ci/directory and a new workflow,.github/workflows/intel-ci.yml. The workflow buildsconda-recipe-cffor every platform and Python version the recipe declares, and tests each package in a clean conda-forge environment withci/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_random 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 forconda-recipe-cf/first and build Linux and Windows on GitHub-hosted runners.hooks.pyinstalls the test requirements fromci/config.yml, the way Jenkins does.ci/test.py: runspytest --pyargs mkl_randomagainst the installed package and writes a JUnit report.ci/benchmark.py: becausebenchmarks/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_random {platform} Python {python}, asconda-package-cf.ymlnames 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 onesconda-package-cf.ymlbuilds today, forci/matrix.py, andnumpy: '2'. Without a NumPy variant, conda-build falls back to NumPy 1.26, which has no builds for Python 3.13 and newer.conda-package-cf.ymlpasses--pythonand--numpyitself, so it is unaffected.ci/README.mdand AGENTS.md notes.A pull request builds the oldest and the newest regular Python versions on Linux and Windows; pushes to
masterand tags build them all.Miniforge is pinned to 26.7.2-0. Miniforge 26.9.4-0, released on 22 October, makes
setup-miniconda'sconda initfail on Windows runners, and the existingconda-package*.ymlworkflows, which installlatest, hit it too on this pull request.Overlap with #202. It also sets
numpy: '2'inconda_build_config.yamland drops Python 3.10, so whichever lands second needs a small rebase, and if 3.10 goes it should leave thepython:list here too.conda-package-cf.ymlandintel-ci.ymlnow both buildconda-recipe-cf; retiring one can be a follow-up.Verification
ci/test.pyagainst each package: 380 passed on each platform and version.pre-commit runon every changed file, all hooks passing, andzizmoronintel-ci.yml, no findings.python ci/matrix.pylists 14 builds, Linux and Windows for 3.10 to 3.15 and 3.14t; with--event pull_requestit lists 3.10 and 3.15 on both.ci/config.ymlloads with gh-ci's own parser.Not verified
ci/benchmark.pyagainst mkl_random's suite. The same script ran mkl_fft's.