Repository navigation
ci(release): start a release's notes at the previous release, not the previous tag - #211
Merged
Merged
Conversation
… previous tag A tag that main's CI keeps off PyPI gets no GitHub release. Starting the next release's notes at that tag left its pull requests out of every release's notes.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
- Read every release, not the newest 100, so an old tag's re-run still finds the release before it. - CONTRIBUTING.md: release notes start at the previous release, and a tag that main's CI kept off PyPI has none.
…rom-previous-release
revan-aleti
approved these changes
Oct 15, 2026
psinghal20
approved these changes
Oct 15, 2026
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
3 participants
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.
What and why
Since #193, a tag whose commit does not pass
main's CI is not published, so it gets no GitHub release. Thereleasejob starts a release's notes at the previous tag. Thus after a blocked tag, the next release's notes start at the blocked tag, and the pull requests that the blocked tag contains are in no release's notes. This has occurred once: v0.9.1329 did not passmain's CI, and the notes of v0.9.1330 start at v0.9.1329, so #157 is in no release's notes.The notes now start at the newest earlier tag that has a GitHub release. The tags are still sorted by version, as before, so a re-run of an older tag does not start at a later release. If no earlier tag has a release, the job gives no start tag, as before for the first tag.
How it was tested
The tag selection ran locally with
bash -eo pipefail, as in Actions, in a repository with the tags v0.9.8 to v0.9.12 (v0.9.9 and v0.9.10 sort by version, not as text):gh api --paginate .../releasesgives every release's tag, and the start tags of v0.9.1327 to v0.9.1329 are the tags before them. v0.9.1329 did not passmain's CI and has no release, so the next release starts at v0.9.1328.actionlint: no findings.
The PR appears safe to merge.Summary
Release notes now start at the newest earlier version tag with a GitHub release.
Reviews (3) · Last reviewed commit: "Merge remote-tracking branch 'origin/mai..." · Reviewed by Greptile