Repository navigation
馃懛 ci: unify release preparation - #867
Draft
gaborbernat wants to merge 48 commits into
Draft
gaborbernat wants to merge 48 commits into
gaborbernat wants to merge 48 commits into
Conversation
Prepare releases with the repository App, verify the generated tree with prek, and render GitHub notes from the tagged changelog. Pin the release toolchain so PR rehearsals and tag jobs install the same versions.
Keep one section for each PyPI version and carry user-facing notes from unpublished tags into the next published version. Explicit anchors keep release and category links stable when later entries are added.
The release workflow consumes pylock.toml, so uv.lock had no consumer or updater. Remove the unsupported Other changes guidance and wrap historical changelog entries without changing their rendered notes, apart from correcting malformed inline literals in 3.31.0.
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:14
aff78ec to
cb86189
Compare
gaborbernat
force-pushed
the
fix/release-contract
branch
from
October 21, 2026 07:17
cb86189 to
c668ea8
Compare
Stage only missing distributions and verify the full PyPI file set before creating the GitHub Release. A retry can resume a partial upload while changed files still fail verification.
Require a matching GitHub draft before PyPI staging. The zero-missing retry path must not publish a Release when draft staging failed.
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.
Filelock release preparation now uses the shared Actions for version selection, RST changelog assembly, patch validation, App-authored commits and tags, and GitHub notes. The 138 PyPI versions have changelog sections with stable category anchors and human credits.
On a retry, a keyless job compares the validated distributions with PyPI and records only missing filenames. The OIDC job uploads that subset, with
skip-existinglimited to races on those filenames. A separate keyless job checks the complete filename and SHA-256 set before GitHub Release creation; a changed, extra, or yanked PyPI file fails that check.The App key is available only to the final preparation job, after a keyless job formats and checks the patch. On tags, read-only jobs validate source, build distributions, select the previous tag, and render notes. Separate Contents write jobs fetch GitHub contributor metadata and stage an exact draft after note rendering. PyPI trusted publishing follows; the final writer publishes the draft after exact PyPI postflight. A retry resumes an identical draft or accepts an identical published Release; a different title or body fails validation. The old writer edited an existing Release body, including a divergent one.
The full selectable
pylock.tomlincludes the build backend and applies a seven-day dependency cutoff to weekly refreshes. This draft pins github-workflows #3 and locks release-creator 0.5.1 from PyPI. Historical GitHub Release bodies and mismatched old tags need the planned live backfill after the code merges.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.