Repository navigation
馃懛 ci: unify release preparation - #637
Draft
gaborbernat wants to merge 31 commits into
Draft
gaborbernat wants to merge 31 commits into
gaborbernat wants to merge 31 commits into
Conversation
gaborbernat
added
documentation
gaborbernat
changed the title
Use the shared release Actions and a locked toolchain for preparation and publication. Reconcile historical changelog sections, credits, categories, and stable Sphinx anchors so the same source can render GitHub Release notes.
The release-only pylock omitted other dependency groups and narrowed the usable Python range. Export all selections from uv's project resolution and keep release installs scoped to their group.
gaborbernat
force-pushed
the
fix/release-contract
branch
from
October 21, 2026 07:06
c26fdf3 to
94d7447
Compare
The shared build action now checks backend hashes before building the wheel and source distribution. Regenerate the full lock with a seven-day age cutoff so the backend and release tools use the same policy.
Select missing files from the validated build, then verify every PyPI digest before reconciling the GitHub Release. Match backend constraints to the build interpreter and bound uv versions.
Use release-creator 0.5.0 from the project lock. Open weekly release-tool PRs with the repo-only App so pull request checks run on those changes. The App needs Pull requests write as well as Contents write.
Use the current shared actions and release-creator 0.5.1 to enforce the full project lock during release work. Rerun bot PR cooldown checks daily after their seven-day age gate.
This branch has not been deployed
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.
Use github-workflows PR #3 for release preparation, patch validation, App-authored commits and tags, hash-constrained distribution builds, and GitHub notes. The full
pylock.tomlincludes a selectable Hatchling backend group and uses a seven-day package age cutoff. The full lock selects release-creator 0.5.1 from PyPI.The tag workflow checks existing PyPI filenames and digests, selects missing files from the validated build for OIDC upload, creates or verifies the matching GitHub Release before PyPI, then verifies the complete published set before publishing any draft. The keyless build action selects backend constraints for the same Python version it uses to build the wheel and sdist. All supported group and build selections resolve on Linux, macOS, and Windows.
The Sphinx changelog has user-facing categories, stable release and category anchors, and human credits. All 91 PyPI-backed historical GitHub Release bodies have read-only previews from the tracked changelog and generated contributor metadata; they match the prior reviewed renders byte for byte. The existing GitHub Releases for 3.0.1 and 4.9.3 have no matching PyPI versions or assets; their source changes appear in the next published releases. Please review those two orphan releases before any cleanup. Historical GitHub bodies will be written only after the release migration is approved and a new release passes.
The PyPI description uses
hatch-fancy-pypi-readmewith the existing README content. The wheel declares its import name and drops the deprecated license classifier.The PR gate requires the shared hook-update cooldown.
Release jobs now install only the tool groups they use from the full project lock. PyPI staging no longer waits for GitHub notes; upload still waits for the staged draft.