Skip to content

Regenerate CI with xmsconan 2.23.0 - #132

Merged
gagelarsen merged 1 commit into
masterfrom
bump/xmsconan-2.23.0
Aug 24, 2026
Merged

Regenerate CI with xmsconan 2.23.0#132
gagelarsen merged 1 commit into
masterfrom
bump/xmsconan-2.23.0

Conversation

@gagelarsen

Copy link
Copy Markdown
Member

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.

Why

xmsconan 2.22.0 made --wheel-dir a request build.py must satisfy, exiting 1 when no complete set of wheels comes out. The workflow passes the flag on every build type, and [matrix].pybind_build_types defaults to Release only — so a Debug leg has no pybind configuration to extract a wheel from and fails:

 >> All configurations built successfully.
 >> No pybind package found to extract.
error: --wheel-dir wheelhouse was given but no complete set of wheels was extracted; see the message above.

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.py is regenerated on every CI run, so the floating xmsconan>=… --upgrade pin delivered the breaking change automatically. The workflow YAML is committed, so the fix only arrives by regenerating. xmsconan 2.23.0 gates the flag on matrix.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:

  • Third-party actions pinned to commit SHAs, tag kept 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 CI uses. It was installing whatever pip install conan resolved; a conan minor bump can change package_id computation, and a coverage run resolving different package ids than the build workflow is measuring a different set of binaries.
  • actions/setup-python v2 → v5 on the flake job.
  • flake8-tidy-imports added. 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 the same green as a run that had checked it.
  • xmsconan floor 2.21.0 → 2.23.0.

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.
@gagelarsen
gagelarsen merged commit 6f15ba4 into master Aug 24, 2026
36 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant