Add workflow: auto-release on PR merge to main#185
Open
Ankur-singh wants to merge 3 commits into
Open
Conversation
Creates a GitHub Release every time a PR is merged into main. The version bumps the patch of the latest GitHub Release; on the first run (no release yet) it seeds the starting point from pyproject.toml (v0.3.0). Release versioning is independent of the in-code version after the seed, and the workflow never commits back to main (no trigger loop). Each release is tagged at the merge commit with auto-generated notes from the merged PRs.
Ankur-singh
requested review from
alec-flowers,
csahithi,
ishandhanani and
nlevin-ui
as code owners
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #185 +/- ##
=======================================
Coverage ? 65.37%
=======================================
Files ? 67
Lines ? 8255
Branches ? 0
=======================================
Hits ? 5397
Misses ? 2858
Partials ? 0 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Start the release series at v1.0.0 instead of seeding from pyproject.toml; subsequent merges bump the patch (v1.0.1, v1.0.2, ...).
Select the highest existing release with 'sort -V' instead of the most recently created one. Only the patch is incremented, so publishing a higher major/minor by hand (e.g. v1.1.0) makes the next merge continue from there (v1.1.1). Also fixes numeric ordering (v1.0.10 > v1.0.9).
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
2 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
Adds
.github/workflows/release.yaml— a GitHub Release is created automatically every time a PR is merged intomain.How it works
pull_requestclosedonmain, gated bymerged == true(fires only on real merges, not closed-without-merge or direct pushes).sort -V), so release versions are independent of the in-code version. On the first run only (no release exists yet) it seeds the start atv1.0.0. Thenv1.0.1,v1.0.2, …v1.1.0) and the next merge continues from there →v1.1.1.v0.5.5.post2tag is ignored with no special-casing.gh release create <tag> --target <merge_commit_sha> --generate-notes— tags the merge commit and generates notes from the merged PRs.main(so no trigger loop);pyproject.toml/__init__.pyare untouched. Needs onlycontents: write.releasegroup serializes near-simultaneous merges so they don't race on the same version.Version logic (verified locally)
v1.0.0v1.0.0v1.0.0v1.0.1v1.0.9,v1.0.10v1.0.10v1.0.11v1.0.3,v1.1.0(manual minor bump)v1.1.0v1.1.1Validation
yaml.safe_loadparses the workflow cleanly.bash -npasses on the version-compute step.sort -Vselection dry-run under bash across the scenarios above (incl. numeric orderingv1.0.10 > v1.0.9and manual minor bumps).v1.0.0.