Skip to content

Pin cibuildwheel in the release workflow to avoid CI drift #10

Description

@titusz

Context

The v2.24.6 release build failed on all Windows jobs (run 30839446049). Root cause: wheels-to-pages.yml installs cibuildwheel unpinned (pip install cibuildwheel), and between the v2.24.5 release (May 2026, cibuildwheel 2.x) and v2.24.6 (August 2026, cibuildwheel 4.1.1) the default behavior changed: 4.x runs delvewheel repair on Windows by default. Repairing the cross-compiled win_arm64 wheel fails on the x64 runner because no ARM64 msvcp140.dll is available to vendor:

FileNotFoundError: Unable to find library: msvcp140.dll

The immediate breakage was fixed in c5abc36 by disabling the Windows repair step (repair-wheel-command = "", matching upstream), but the underlying exposure remains: any future cibuildwheel behavior change lands unreviewed, and it surfaces at the worst possible time — during a tagged release build.

Proposal

Pin cibuildwheel in .github/workflows/wheels-to-pages.yml, e.g.:

- name: Install cibuildwheel
  run: python -m pip install cibuildwheel==4.1.1

and bump the pin deliberately (reviewing the changelog) rather than implicitly at release time. Optionally let Dependabot/Renovate propose pin bumps so updates still arrive regularly but as reviewable PRs.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions