[pimlock]

Summary

Stable releases currently trigger Kitmaker through GitLab to publish Python wheels. Publish directly from release.yml to PyPI using Trusted Publishing and the pypi GitHub environment. Development and prerelease wheels remain GitHub Release assets without PyPI uploads.

Related Issue

Closes #5156

Changes

• Upload the built wheel from a dedicated job in release.yml, with job-scoped id-token: write and a pinned PyPA publishing action. Check the stable tag's source commit, wheel name/version, and release checksum before uploading. Skip existing uploads on release retries.
• Remove the stable and development Kitmaker triggers, the old wheel-publish.yml workflow, and GitLab trigger credential references.
• Keep stable docs after PyPI publication, include PyPI and docs in the stable publication check and failure notification, and update the release guidance and regression tests.

flowchart LR
    B[Build stable artifacts] --> R[Publish release assets and other packages]
    R --> P[Verify wheel and publish to PyPI]
    P --> D[Publish stable docs]

Loading

The configured PyPI publisher trusts NVIDIA/OpenShell, workflow release.yml, and environment pypi. The GitHub environment currently allows main and has no required reviewers. Support release branches must be explicitly allowed before dispatching Release. No stored PyPI API token is required.

Release Notes

Testing

• 35 existing release-tooling and updated docs-sync tests pass.
• Ruff lint and format checks pass for the changed docs-sync test file.
• Zizmor reports no high-severity findings in the four changed workflows.
• Job dependencies and local reusable-workflow references resolve across all 58 workflows; no Kitmaker trigger references remain in the release workflows.
• git diff --check passes.
• Actionlint 1.7.12 reports two existing concurrency.queue syntax errors in release.yml and release-prerelease.yml. The unchanged versions produce the same errors; no new findings were reported. ShellCheck and Pyflakes were disabled for this check.
• Live PyPI authentication and upload. No release workflow was dispatched during validation.

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Release guidance and Fern workflow documentation updated

[github-actions]

🌿 Preview your docs: https://nvidia-preview-pr-5157.docs.buildwithfern.com/openshell

[pimlock]

a1cadbc changes publish-pypi to download the wheel and openshell-checksums-sha256.txt from the stable GitHub Release instead of the run's python-wheel build artifact.

Why:

• Retries can finish a failed PyPI upload. A new Release run rebuilds the wheel, and the rebuilt bytes differ from the released asset because the build does not pin file timestamps. The release keeps its original assets (overwrite_files: false), so checking a rebuilt wheel against the release checksum fails and nothing could publish the wheel. The run artifact also expires after 5 days, and this PR removes wheel-publish.yml, which was the manual republish path. Publishing the release asset works from any later run for the same tag.
• PyPI gets exactly what GitHub serves. PyPI never allows a published file to be replaced, so the uploaded bytes should be the ones users download from the release and the release checksum lists. The checksum check now verifies the published asset instead of comparing this run's build against what this run uploaded.
• It matches the previous wheel path. wheel-publish.yml checked the wheel against the release's assets before Kitmaker published it. Only the GitLab step is removed.

The release is published before this job runs: publish-pypi needs publish, whose release job uploads release/*.whl and the checksum file, and whose check-publication job fails if that upload did not succeed.

This differs from the other publishers (snap and GHCR use run artifacts; npm rebuilds from the source commit). Those can be corrected or rebuilt from a fixed commit; a PyPI file cannot.