Repository navigation
Build and test conda packages and wheels - #3151
jharlow-intel wants to merge 1 commit into
Conversation
73735c3 to
f70dbd8
Compare
6aca46e to
e9f220a
Compare
|
View rendered docs @ https://intelpython.github.io/dpnp/pull/3151/index.html |
|
Array API standard conformance tests for dpnp=0.22.0dev1+10.g541d81971 ran successfully. |
| - name: Build and run the recipe tests | ||
| env: | ||
| PYTHON_VERSION: ${{ matrix.python }} | ||
| run: python ci/build.py --python "$PYTHON_VERSION" --output "$RUNNER_TEMP/output" |
There was a problem hiding this comment.
The conda packages and the wheels now build and test only against released dpctl (conda-forge, PyPI); the removed workflow used dppy/label/dev first. So dpnp can no longer require a dpctl dev build: dpctl>=0.24.0dev0, as #3169 sets in pyproject.toml, makes the wheel install fail, and the same in the recipe fails the conda build, as only 0.23.0 is released. Is that intended? If not, build.py --channel dppy/label/dev --channel conda-forge and the same channel in hooks.py would keep it.
|
|
||
| Returns its exit status, or None if it hung on every attempt. | ||
| """ | ||
| for attempt in range(1, ATTEMPTS + 1): |
There was a problem hiding this comment.
This retries a suite only when it hangs. The removed workflow reran any failed suite (2 attempts, 3 for the tensor tests) and stopped a stuck tensor test after 120 s with pytest-timeout (IntelPython/dpctl#1954). Now one flaky failure fails the job and blocks the upload, and one stuck tensor test costs 20 minutes. Could it rerun on any failure, and keep --timeout=120 --timeout-method=thread for dpnp.tests.tensor?
| - '*DPCTLSyclInterface*' | ||
| - '*/dpnp_backend_c.dll' # [win] | ||
| number: {{ GIT_DESCRIBE_NUMBER }} | ||
| ignore_run_exports: |
There was a problem hiding this comment.
The removed rattler_recipe.yaml ignored the mkl-dpcpp run export of mkl-devel-dpcpp, and this recipe does not. conda-forge's mkl-devel-dpcpp 2026.2.0 exports mkl-dpcpp >=2026.2.0,<2027.0a0, which pulls in onemkl-sycl-datafitting and onemkl-sycl-stats. dpnp uses neither, and these packages now go to dppy/label/dev. Could - mkl-dpcpp go back into ignore_run_exports?
|
|
||
| examples: | ||
| name: Test examples | ||
| needs: linux |
There was a problem hiding this comment.
needs: linux waits for the whole reusable workflow, tests included: a failing Linux test now skips the examples and the Array API comment, which needed only the build before. The examples also lost 3.14t. As this workflow now repeats intel-ci.yml's builds for 3.12-3.14, could both jobs move there, with needs: build and a package every event builds (3.14t or 3.15)?
| KEEP = ( | ||
| "PATH", | ||
| "HOME", | ||
| "USER", | ||
| "LANG", | ||
| "TERM", | ||
| "TMPDIR", | ||
| "TZ", | ||
| "http_proxy", | ||
| "https_proxy", | ||
| "no_proxy", | ||
| "HTTP_PROXY", | ||
| "HTTPS_PROXY", | ||
| "NO_PROXY", | ||
| "SSL_CERT_FILE", | ||
| "REQUESTS_CA_BUNDLE", | ||
| "CONDA_PKGS_DIRS", | ||
| "SYSTEMROOT", | ||
| "SYSTEMDRIVE", | ||
| "WINDIR", | ||
| "COMSPEC", | ||
| "PATHEXT", | ||
| "TEMP", | ||
| "TMP", | ||
| "USERPROFILE", | ||
| "APPDATA", | ||
| "LOCALAPPDATA", | ||
| "PROGRAMDATA", | ||
| "NUMBER_OF_PROCESSORS", | ||
| "PROCESSOR_ARCHITECTURE", | ||
| ) |
There was a problem hiding this comment.
test_env keeps only KEEP and the GH_CI_* values it sets, so GH_CI_DEVICE never reaches test.py. On a GPU runner (vars.GH_CI_RUNNER) with a broken GPU driver the tests then pass on the CPU device, which ci/README.md says cannot happen. ONEAPI_DEVICE_SELECTOR is dropped too. Could both go into KEEP?
| .. code-block:: bash | ||
|
|
||
| conda-build conda-recipe -c https://software.repos.intel.com/python/conda/ -c conda-forge --override-channels | ||
| conda-build conda-recipe -c conda-forge --override-channels |
There was a problem hiding this comment.
conda_build_config.yaml now lists six Python versions, so this command builds six packages, about six times the old build time. Adding --python 3.14 here would keep it to one.
| | --- | --- | --- | | ||
| | pre-commit (`Check`) | `.github/workflows/pre-commit.yml` | yes | | ||
| | conda build and tests, Linux and Windows, py3.13-3.15 and 3.14t (`Test (...)`) | `conda-package.yml` | yes | | ||
| | conda packages and wheels built and tested, Linux and Windows, py3.11-3.15 and 3.14t for conda, py3.10-3.14 and 3.14t for wheels (`Test <Platform> Python <version>`, `Test <Platform> Wheels Python <version>`); the conda matrix is `conda-recipe/conda_build_config.yaml`, the wheel matrix the Python classifiers in `pyproject.toml`; see `ci/README.md` | `intel-ci.yml` | no | |
There was a problem hiding this comment.
The wheels are 3.11-3.14 and 3.14t: pyproject.toml has no 3.10 classifier, as #3173 dropped 3.10. Also, the old row was required on master. Is a required check planned for intel-ci.yml, or should branch protection just drop the old Test (...) checks?
| @@ -0,0 +1,655 @@ | |||
| """ | |||
There was a problem hiding this comment.
matrix.py, build.py, hooks.py and benchmark.py have no license header, while test.py and install_icx.py have one. AGENTS.md asks for the BSD-3 header from a neighbouring file on every new file.
| workflow: intel-ci.yml | ||
| artifacts: | ||
| conda: "dpnp {platform} Python {python}" | ||
| wheel: "dpnp {platform} Wheels Python {python}" | ||
| test: | ||
| requires: [pytest, pytest-xdist, scipy] | ||
| # The wheels' requirements have no OpenCL CPU runtime of their own, which the tests need | ||
| wheel_requires: [pytest, pytest-xdist, scipy, intel-opencl-rt] | ||
| benchmark: | ||
| # PyYAML, which asv needs, has no PyPI wheel for every Python the recipe declares. | ||
| requires: [scipy, pyyaml] | ||
| # conda-forge lacks asv for some Python the recipe declares; the wheel on PyPI fits all. | ||
| pip_requires: [asv] |
There was a problem hiding this comment.
Nit: Nothing here runs benchmark.py or reads workflow, artifacts and benchmark from this file, and the JUnit reports test.py writes are not uploaded. Are they for another Intel CI service, and is ci/ copied from a shared template (it also has rattler-build, macOS and conda-recipe-cf paths dpnp does not use)? A line in ci/README.md would help either way.
| * Moved `blas`, `fft`, `lapack`, `sparse` and `vm` extensions into `dpnp/libtensor/extensions` [#3131](https://github.com/IntelPython/dpnp/pull/3131) | ||
| * Moved the libtensor headers shipped with dpnp from `dpnp/tensor/libtensor/include` to `dpnp/libtensor/include`, and changed `dpnp.get_include` to return that directory [#3131](https://github.com/IntelPython/dpnp/pull/3131) | ||
| * Improved performance of `dpnp.scipy.sparse.csr_matrix.sort_indices` by sorting once on a combined row and column key instead of in two passes [#3134](https://github.com/IntelPython/dpnp/pull/3134) | ||
| * Changed the CI to build and test the conda packages of `conda-recipe` and the wheels with Intel CI (`ci/`, `.github/workflows/intel-ci.yml`); the conda packages now require `onemkl-sycl-sparse` and the wheels declare the oneAPI runtime wheels in their metadata [#3151](https://github.com/IntelPython/dpnp/pull/3151) |
There was a problem hiding this comment.
Nit: The dev packages from the removed recipe already required onemkl-sycl-sparse. For their users the change is that the dppy/label/dev packages are now built against conda-forge only; could the line say that instead?
Adds a ci/ directory and .github/workflows/intel-ci.yml, which build the conda packages and the wheels for every declared platform and Python and test each with ci/test.py. A pull request builds the oldest and the newest regular Python and the newest free-threaded one, and every push and tag run gets a concurrency group of its own. 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. The dev uploads to anaconda.org move to intel-ci.yml, and the Array API conformance and pybind11 examples jobs to conda-package-cf.yml. The benchmarks take PyYAML from conda-forge, as PyPI has no Python 3.15 wheel for it yet. ci/build.py refuses two built packages with the same file name, which would overwrite each other in its flat output directory, and takes METADATA's line ending from its headers. conda-build records the commit each conda package came from in info/about.json, and LDFLAGS links the Linux wheels' libraries with full RELRO.
e9f220a to
b53329b
Compare
Adds
ci/and.github/workflows/intel-ci.yml, which build the conda packages and 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/. It builds against conda-forge'sdpctl0.23.0, which has no 3.10, so its Pythons start at 3.11. The Intel-channel recipe, withrattler_recipe.yaml, andconda-package.ymlare removed; that workflow's Array API conformance and pybind11 examples jobs move toconda-package-cf.yml.dppy/label/devuploads and their cleanup move intointel-ci.yml, for pushes tomasterand tags only.dpctlwheel on PyPI, and require the oneAPI runtime wheels (dpcpp-cpp-rt,intel-sycl-rt,mkl,onemkl-sycl-*), as the PyPI wheels do. PyPI has nodpctlfor 3.15 yet, so the 3.15 classifier is dropped until it does.ci/test.pyrunsdpnp.tests, thendpnp.tests.tensor, against the installed package, and fails when it finds no SYCL device: the OpenCL CPU device in Actions, or a GPU withGH_CI_DEVICE=gpu.The required checks on
mastercome fromconda-package.yml, so they need replacing with this workflow's, such asTest Linux Python 3.11, before this can merge.Validation, with a temporary push trigger on this branch: run 41672888041 built and tested the conda packages for 3.11 and 3.15 and the wheels for 3.10 and 3.14, on Linux and Windows, and
conda-package-cf.yml, pre-commit and zizmor passed. An earlier full-matrix run passed every declared Python. Not run yet: a GPU, and the uploads, which onlymasterand tags do.