Recognize a no-release label as its own release reason - #184
Open
cratis-stagehand[bot] wants to merge 4 commits into
Open
Recognize a no-release label as its own release reason#184cratis-stagehand[bot] wants to merge 4 commits into
cratis-stagehand[bot] wants to merge 4 commits into
Conversation
added 4 commits
August 30, 2026 20:57
The action only ever checked major/minor/patch labels; a pull request merged with no bump label reported reason 'no-label' regardless of whether it was actually unlabeled or deliberately carried a no-release decision. Consuming workflows that fail on 'no-label' (the correct response to a forgotten label) then also failed on every intentional no-release merge, indistinguishable from the mistake they were meant to catch. Add a configurable no-release-labels input (default 'no-release') and a dedicated 'no-release' reason, checked ahead of the bump labels and excluded from unintendedReasons so it resolves as expected rather than as a lost release.
Cover the default and custom no-release-labels input, the Versions.getNextVersionFor and HandleVersion end-to-end paths for a pull request labelled no-release, and lock down that unintendedReasons excludes it.
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.
Added
no-release-labelsinput (defaultno-release) and a dedicatedno-releasereason on thereasonoutput, for a merged pull request that deliberately publishes nothing.Fixed
no-releaselabel was previously indistinguishable from one that simply forgot a version label: neithermajor,minornorpatchmatched, so the action reportedreason: no-labeleither way. A consuming workflow that (correctly) fails onno-labelthen also failed on every deliberate no-release merge.Context
Cratis/Components' Publish workflow failed on run 33334724595: PR Cratis/Components#222 was correctly labelled
no-releaseper Cratis/Components' ownpull-requests.mdconvention and passed the org-wideverify-release-intentgate, but this action had no concept of that label at all and fell back tono-label, which Components'verify-publishedjob (correctly, per its own design) treats as a failure.Cratis/Components#223
Verified
yarn ci(typecheck, lint, specs with coverage, build) passes locally - 66 files / 133 specs green, including 5 new specs covering the default and a customno-release-labelsinput, theVersionsandHandleVersionpaths for ano-release-labelled pull request, and thatunintendedReasonsexcludes it.dist/rebuilt from the changed source and committed, per this repo's own## Developingguidance (CI fails ifdist/is stale).Not verified
publish.ymlto a new tag of this action, since that depends on this PR being reviewed, merged and released first. Once a new tag exists, Components can bump its pinned SHA to pick up this fix.