Repository navigation
Release on merge: one approval releases everything merged since the last release - #45
Merged
Merged
Conversation
…all of main as one version A merge that changes what the package ships starts a release, which waits in the release environment. Approved, it releases main as it is then, versioned by scripts/release-plan.sh from the biggest change merged since the last tag: a release label on a pull request, or else what its files are. It publishes with provenance, commits the version to main, tags it and creates the GitHub release. Prepare release and release PRs go.
…re, and survive a same-version or conflicting merge - release-plan.sh: only an unknown commit (HTTP 422) counts as pushed straight to main; any other gh error stops the plan instead of planning a minor. The release-commit skip matches a whole Release vX.Y.Z subject. - publish.yml: the release plan step sets pipefail, so tee can't hide the plan failing, and requires npm reachable. - publish.yml: the release commit allows a version main already has, a failed merge aborts and retries and ends with the hand-merge message, and a pull request changing release-pack.sh runs the dry run. - RELEASING.md: the hand merge uses the workflow's message, and the GitHub release is made by hand after it.
…was built, and stands down when overtaken
…ersion line doesn't block the merge
…ops the dispatch Prepare release used
…use the same script; Drivine has none, and none with bump
Closed
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.
Releasing desk took a Prepare release run, a release PR, a merge and an approval, and a feature wasn't out until someone remembered to do all four. Now a merge is the release, held for one approval.
How it works (RELEASING.md has it all):
mainthat changes what the package ships (src/, README,llms.txt,package.json, the files that build it) starts Release: plan, CI gate, a dry-run pack, then areleasejob that waits in thereleaseenvironment.main.scripts/release-plan.sh: the last release (newest tag, or npm'slatestif later), bumped by the biggest change merged since. Arelease: major|minor|patch|nonelabel decides; without one, a PR that changessrc/is minor, one that changes only other shipped files is patch, and one that ships nothing is none.main("Release vX.Y.Z", onlypackage.jsonand the lock), tags it, and creates the GitHub release with notes since the last one.mainwithpublishticked, releases whatmainholds.Safety. It refuses to release on top of a version npm has but no tag records, stops the plan on any GitHub error rather than guessing a bump, retries the merge into
main(with-X theirs, as the release commit changes only version lines), and gives the hand recovery for each failure in RELEASING.md. A pull request can't publish: thereleaseenvironment deploys only frommain, and npm's trusted publisher is bound to it.Tested by simulating each step from the YAML under
bash -e -o pipefailagainst local repos: fast-forward and movedmain, conflicts, a same-versionmain, and sequences of merges approved in each order, including a release landing while another waits.release-plan.shwas run read-only against this repo: since v0.36.0 it finds #42 (none) and #43 (minor).npm run checkpasses.Merging this starts no release, as it ships nothing.