fix(ci): stop releasable-commit-types flagging release-please's own release commit - #10287
Merged
Merged
Conversation
…elease commit publishedSourcePrefixes includes <pkg>/package.json, and a release-please release commit is `chore(release): …` whose entire job is to write the new version into exactly that file. So the guard matched by construction on every release PR it ever ran against -- #10283 surfaced it, where the flagged claim ("would merge green and then never reach npm") is exactly backwards: that commit is the one that performs the release, and a maintainer cannot reword it because release-please generates it. This file's own isPublishedFile note already warns that a guard firing on the ordinary case is a guard that gets disabled. The exemption keys on what the diff DID, not on the subject: a commit borrowing the `chore(release):` subject while editing a dependency range or an exports map still strands a real change, so only a manifest whose sole changed lines are the "version" field is dropped. A commit left with no other published-source path is release-please's own and is not stranded; a mixed commit still reports its remaining paths. An empty diff proves nothing and stays flagged, which keeps the default accessor's behaviour unchanged. Closes #10286
Contributor
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #10287 +/- ##
=======================================
Coverage 92.31% 92.31%
=======================================
Files 939 939
Lines 114816 114816
Branches 27729 27729
=======================================
Hits 105989 105989
Misses 7527 7527
Partials 1300 1300
Flags with carried forward coverage won't be shown. Click here to find out more. |
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.
Closes #10286. Unblocks #10283, whose
drift-checks-historyis red for exactly this reason.What
releasable-commit-types:checkfails on every release-please release PR, flagging release-please's own release commit:publishedSourcePrefixesincludes<pkg>/package.json, and a release commit's whole job is to write the new version into that file underchore(release):— a hidden type. The match is structural, so it fires on every release PR, and the message's claim is backwards: that commit is the one that performs the release, not one that will never reach npm. A maintainer also cannot fix it by rewording, because release-please generates the commit.The file's own
isPublishedFilenote already makes the argument: "a guard that fires on the ordinary case is a guard that gets disabled."Why keyed on the diff, not the subject
Matching
chore(release):in the subject would be simpler and weaker — a hand-written commit borrowing that subject while editing a dependency range or anexportsmap still strands a real change. SoisVersionOnlyManifestBumpexempts a path only when its diff's sole changed lines are the"version"field. Consequences, all tested:Verified against the live failure
Ran the fixed code over #10283's real commit range (
origin/main...release-please--branches--main--components--ui-kit), with realgit showdiffs:Tests
33 pass. New coverage: the release commit is allowed; a
chore(release):that also edits a dependency range is still flagged; a mixed commit reports only its non-version paths; no-diff still flags; plus five directisVersionOnlyManifestBumpcases including diff-header lines and a non-manifest file. The original #9937 recharts regression test is untouched and still passes.