Repository navigation
build(ci): build and smoke-test the release wheels - #44
Conversation
.github/workflows/wheels.yml builds the published distribution as workflow artifacts (manual runs, published releases, and pull requests that touch the packaging); publishing stays a separate step: - sdist, checked with twine; - Linux x86-64 (cibuildwheel, manylinux_2_28, image GCC toolset): OpenBLAS and the Fortran runtime bundled by auditwheel, built for x86-64-v3 (CABLEDYN_TARGET_AVX2), as the Windows release; - macOS arm64 (cibuildwheel, Homebrew gfortran and OpenBLAS, bundled by delocate, deployment target 14.0); - Windows x86-64 (release/build_windows_wheel.ps1): the static release configuration with IFX and MSVC and the release's pinned reference LAPACK; dumpbin checks that the library and the driver import only Windows system DLLs. release/smoke_test_wheel.py installs nothing itself: run in a clean environment with the wheel installed, it requires the package to load the library it carries and select the driver it carries, the driver to report the expected build (--expect-build), and a standalone deck to run. tests/test_packaging_metadata.py keeps the reference LAPACK version, checksum and flags of the wheel and release scripts equal. Signed-off-by: Jae Hoon Seo <jaehoon.seo@inha.ac.kr>
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2ae034a7f5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2ae034a7f5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The wheels workflow runs release/build_windows_wheel.ps1 with Windows PowerShell 5.1, whose Expand-Archive refuses the .whl extension (NotSupportedArchiveFileExtension), so every Windows wheel build would have stopped before the dependency audit. The wheel is now extracted with System.IO.Compression.ZipFile, which reads it by content. In the same version, Get-ChildItem -LiteralPath ignores -Include and listed every file of the package as a binary, which made the count check meaningless and ran dumpbin on Python modules. The binaries are now filtered on their extension, and the wheel must carry exactly the library and the driver in cabledyn/bin. Signed-off-by: Jae Hoon Seo <jaehoon.seo@inha.ac.kr>
|
@codex review |
|
Codex Review: Didn't find any major issues. You're on a roll. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
The static Windows release compiles the core with /Qipo, so its objects are IFX intermediate code that only an IPO link can read. The executables get /Qipo through CMAKE_EXE_LINKER_FLAGS; the shared library, which only the Windows wheel builds in this configuration, did not, and IFX handed the objects to link.exe (LNK1107 in the first wheels run). CMAKE_SHARED_LINKER_FLAGS now carries /Qipo too. The resulting cabledyn.dll imports only SHELL32, KERNEL32 and imagehlp, loads through the Python package, and stops at load with the x86-64-v3 message when the processor check fails. Signed-off-by: Jae Hoon Seo <jaehoon.seo@inha.ac.kr>
|
@codex review |
|
Codex Review: Didn't find any major issues. Keep them coming! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Summary
Second packaging step towards publishing
cabledynon PyPI. #42 made the rootpyproject.tomlbuild a wheel that carries the library and the driver; this PR builds the release wheels in CI and checks each one on its own platform. Publishing stays a separate PR (Trusted Publishing, TestPyPI first).What changes:
.github/workflows/wheels.ymlbuilds the distribution as workflow artifacts. It runs on manual dispatch, on a published release, and on pull requests that touch the packaging.python -m build --sdist,twine checkmanylinux_2_28)CABLEDYN_TARGET_AVX2=ONviaSKBUILD_CMAKE_DEFINE)release/build_windows_wheel.ps1: IFX 2025.3.1 Essentials (pinned size and signature, as the release workflow) and MSVCrelease/build_windows_wheel.ps1:dumpbinthat the library and the driver import only Windows system DLLs.release/smoke_test_wheel.pyruns in a clean environment with the wheel installed. It requires:CABLEDYN_LIBRARYor a build tree);PATH);--expect-build x86-64-v3orbaseline);.out.tests/test_packaging_metadata.pykeeps the reference LAPACK version, archive checksum and Fortran flags of the wheel script equal to the release script's.Docs: a table of the three wheels in
DEVELOPMENT.md; CHANGELOG entry.On a processor without AVX2: the x86-64 wheels' driver stops with the start-up message (#43), and so does a Python process when it loads the library. The process exits with status 3 after printing the message. Without the check it would crash at the first AVX2 instruction.
Verification
Local wheel (Windows, conda gfortran,
SKBUILD_CMAKE_DEFINE="CABLEDYN_TARGET_AVX2=ON", the Linux job's route), installed into a fresh venv. The smoke test passes:x86-64-v3 (AVX2);dynamic_chain_current.datruns.--expect-build baselinefails on the same wheel, as it should.Parity test: passes, and fails when a LAPACK pin differs.
Default build (Windows, gfortran, Release, slow tier included): ctest 297/297; pytest 2052 passed;
pre-commit run --all-filesand the Sphinx-Wbuild pass.Not run locally: the Linux, macOS and Windows wheel jobs themselves. This PR's own run of
wheels.ymlis their first test.Checklist
pre-commit run --all-filespassesctest --test-dir build --output-on-failurepassespython -m pytest tests python/testspasses (if Python or validation records changed)[Unreleased](heading added if missing) for user-visible changesdoc/updated for changed inputs, options, or outputs (the install instructions change with the first PyPI release)feat:,fix:,docs:, ...)git commit -s) under theDeveloper Certificate of Origin