[hardening] Verify multi-platform wheel builds and trusted publishing before v1.2.0

[StatPan]

Summary

• Validate the release matrix and the PyPI trusted publishing path before the next tag.

Acceptance Criteria

• Linux x86_64/aarch64, macOS x86_64/aarch64, and Windows x64 wheel jobs complete successfully.
• Trusted publisher settings and pypi environment are confirmed against the repo config.
• Any platform-specific failure is tracked with concrete logs and a follow-up PR.

[StatPan]

Release hardening status update on 2026-04-21:

What was found from prior failed release runs:

• earlier Linux wheel jobs failed in manylinux2014 before build because the container was missing required Perl modules/packages
• later Linux wheel jobs still failed while building vendored OpenSSL because the old manylinux toolchain/binutils could not assemble OpenSSL 3.x sources
• the repo also had no GitHub environment named pypi, even though the workflow expected one

What is now implemented locally / in repo config:

• Linux release wheels use manylinux: 2_28
• Linux before-script installs perl-core and perl-IPC-Cmd where available
• release wheel jobs use RUSTFLAGS=-D warnings
• Release workflow now supports workflow_dispatch with publish=false for build-only matrix validation before tagging
• GitHub environment pypi has been created in the repository settings

Remaining blocker before closing this issue:

• push the workflow changes on a branch
• run Release via workflow_dispatch with publish=false
• confirm all 5 wheel jobs + sdist succeed on GitHub-hosted runners
• then validate the trusted publishing path on the real tag flow

This issue should remain open until the remote matrix is green, because local validation is not enough for release sign-off.

[StatPan]

Remote validation update on 2026-04-21:

• Draft PR: [hardening] enforce release blocker gates #9
• CI run 24708561614: green
• Release build-only run 24708564903: still in progress overall, but Linux wheels (aarch64) has already failed

The release blocker is now narrowed to a concrete platform-specific aarch64 wheel failure under the 5-wheel abi3 matrix. I am pulling the failed job log next and will use that log to decide the next patch, rather than guessing.

[StatPan]

Remote validation update on 2026-04-21:

The failed Linux aarch64 release job was root-caused to interpreter discovery inside the manylinux_2_28-cross:aarch64 container, not OpenSSL assembly or Perl setup.

Failed log excerpt:

• maturin failed
• Couldn't find any python interpreters. Please specify at least one with -i

Follow-up patch pushed:

• commit 2267004 adds -i python3.10 to the Linux manylinux build args so the abi3 wheel has an explicit interpreter in cross builds

A fresh build-only Release dispatch has been triggered on the updated branch.

[StatPan]

Update on release hardening after follow-up workflow cleanup.

What changed on branch issue-2-release-hardening:

• upgraded workflow actions to Node 24-compatible majors
  • actions/checkout@v5
  • actions/setup-python@v6
  • actions/upload-artifact@v6
  • actions/download-artifact@v5
  • astral-sh/setup-uv@v7
• kept the earlier release-matrix hardening in place (abi3 5-wheel matrix, manylinux: 2_28, strict RUSTFLAGS=-D warnings, cross-linux -i python3.10)

Verification status as of 2026-04-21:

• PR CI for commit 07a9c30 is green: run 24708907924
• build-only release validation for the same commit is running: run 24708939195
• that release run is now executing with the upgraded action versions (v5 / v6) rather than the old Node 20-based workflow actions

This closes the externally visible GitHub Actions deprecation warnings that were still leaking from the previous workflow versions; remaining validation is only the build matrix finishing on the refreshed release run.

[StatPan]

Status update on 2026-04-21:\n\nResolved in practice:\n- The 5-job abi3 release matrix is now green on GitHub Actions.\n- A real Release run published successfully via PyPI API token fallback: run 24721365079.\n- PyPI install smoke passed after publish.\n\nStill open:\n- Trusted publishing is still not configured correctly on the PyPI side.\n- The direct validation failure was .\n- The failing OIDC claims included and .\n\nConclusion:\n- This issue should remain open, but it is no longer a wheel-build blocker.\n- Remaining scope is to restore PyPI trusted publishing parity and then switch the workflow back from API token fallback to OIDC.

[StatPan]

Status update on 2026-04-21:

Resolved in practice:

• The 5-job abi3 release matrix is now green on GitHub Actions.
• A real Release run published successfully via PyPI API token fallback: run 24721365079.
• PyPI install smoke passed after publish.

Still open:

• Trusted publishing is still not configured correctly on the PyPI side.
• The direct validation failure was "invalid-publisher: valid token, but no corresponding publisher (Publisher with matching claims was not found)".
• The failing OIDC claims included sub=repo:StatPan/pyjwt-rs:environment:pypi and workflow_ref=StatPan/pyjwt-rs/.github/workflows/release.yml@refs/heads/main.

Conclusion:

• This issue should remain open, but it is no longer a wheel-build blocker.
• Remaining scope is to restore PyPI trusted publishing parity and then switch the workflow back from API token fallback to OIDC.

[StatPan]

Current blocker is concrete: release run 24723638080 is still stuck in the Windows wheel job, and PyPI still shows only 1.2.0. Follow-up fix is switching the Windows maturin target from x64 to the Rust target triple x86_64-pc-windows-msvc and enabling --compatibility pypi checks in the release matrix.

[StatPan]

Follow-up on #18: switching the Windows wheel path off PyO3/maturin-action entirely. The target fix alone did not unblock the job; the branch now builds Windows wheels with native pip-installed maturin on windows-latest.