Regenerate CI with xmsconan 2.23.0 - #132
Merged
Merged
Conversation
CI only. No source, build.toml or version change, and no re-release: 7.0.13 is already published with a complete set of packages, built before any of this landed. xmsconan 2.22.0 made `--wheel-dir` a request build.py must satisfy -- it exits 1 when no complete set of wheels comes out -- while the workflow passed the flag on every build type. `[matrix].pybind_build_types` defaults to Release only, so a Debug leg has no pybind configuration to extract a wheel from, and every Debug leg fails. xmsgrid hit this on 2026-08-21 and xmsmesher on 2026-08-22; xmscore has not pushed since, so it is red on its next run rather than now. xmsconan 2.23.0 gates the flag on `matrix.build_type == 'Release'`, which is how repair, artifact upload and deploy in this workflow were already gated. The fix does not arrive on its own: `build.py` is regenerated on every run and picked up the breaking change through the floating pin, but the workflow itself is committed, so it takes this regeneration to pick up the fix. Also in this regeneration, all from xmsconan 2.23.0: - Third-party actions pinned to commit SHAs with the tag in a trailing comment, in both workflows. A tag is a movable ref in someone else's repository, and these steps run with the workflow's secrets in their environment. - The coverage workflow pins conan to the same `~=2.31.0` series the CI workflow uses. It was installing whatever `pip install conan` resolved, and a conan minor bump can change package_id computation -- a coverage run that resolves different package ids than the build workflow is measuring a different set of binaries. - `actions/setup-python` v2 to v5 on the flake job. - `flake8-tidy-imports` added to the flake job. It registers `banned-modules`, which the generated `.flake8` sets; flake8 ignores config options no installed plugin claims, so the osgeo ban was silently enforcing nothing while the job reported green. - xmsconan floor 2.21.0 to 2.23.0.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CI only — no source,
build.tomlor version change, and no re-release. 7.0.13 is already published with a complete set of packages, built before any of this landed.Why
xmsconan 2.22.0 made
--wheel-dira requestbuild.pymust satisfy, exiting 1 when no complete set of wheels comes out. The workflow passes the flag on every build type, and[matrix].pybind_build_typesdefaults to Release only — so a Debug leg has no pybind configuration to extract a wheel from and fails:xmsgrid hit this on 2026-08-21 and xmsmesher on 2026-08-22. xmscore is not red yet only because nothing has pushed to it since — it would fail on its next run, including a release tag.
Why it needs a commit here
build.pyis regenerated on every CI run, so the floatingxmsconan>=… --upgradepin delivered the breaking change automatically. The workflow YAML is committed, so the fix only arrives by regenerating. xmsconan 2.23.0 gates the flag onmatrix.build_type == 'Release'— how repair, artifact upload and deploy in this same workflow were already gated (Aquaveo/xmsconan#110, Aquaveo/xmsconan#111).Also in this regeneration
All from xmsconan 2.23.0, none of it opt-in:
~=2.31.0series CI uses. It was installing whateverpip install conanresolved; a conan minor bump can changepackage_idcomputation, and a coverage run resolving different package ids than the build workflow is measuring a different set of binaries.actions/setup-pythonv2 → v5 on the flake job.flake8-tidy-importsadded. It registersbanned-modules, which the generated.flake8sets. flake8 ignores config options no installed plugin claims, so the osgeo ban was silently enforcing nothing while the job reported the same green as a run that had checked it.