fix: recover bump files from the version commit even when HEAD has moved past it#136
Merged
Merged
Conversation
…ved past it
GitHub release notes came up empty ("No changelog entries.") whenever the
publish ran on a commit later than the version commit — e.g. a retry after
the first publish was blocked and unrelated CI fixes landed on main.
recoverDeletedBumpFiles assumed the version commit was always HEAD~1..HEAD,
so once HEAD diverged it silently recovered nothing and release bodies fell
back to the empty placeholder. It now finds the most recent commit that
actually deleted .bumpy/*.md files and recovers their content from that
commit's parent.
|
The changes in this PR will be included in the next version bump.
|
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
1 participant
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.
Problem
GitHub release notes came up empty — literally
No changelog entries.— for a whole batch of releases, even though theCHANGELOG.mdfiles had full content. (Observed on a varlock release batch: e.g.@varlock/1password-plugin@2.0.0.)Root cause
Release bodies are generated at draft-creation time from bump files recovered out of git via
recoverDeletedBumpFiles. That function only inspected the singleHEAD~1..HEADdiff, assuming HEAD is always the version commit that deleted the bump files.That assumption breaks when publish runs on a commit later than the version commit — e.g. the first publish attempt was blocked, unrelated CI fixes landed on
main, and publish was retried hours later. By then HEAD has moved past the version commit, theHEAD~1..HEADdiff contains no bump-file deletions, recovery returns[], and the release body falls back to the empty placeholder. TheCHANGELOG.mdfiles are unaffected because they're written and committed at version time.In the observed case the version commit was 6 commits behind the commit the publish (and the release tags) actually ran on.
Fix
recoverDeletedBumpFilesnow locates the most recent commit that actually deleted.bumpy/*.mdfiles (the version commit) viagit log --diff-filter=D, and recovers their content from that commit's parent — instead of assuming it'sHEAD~1.This is a sound anchor because feature PRs only ever add bump files; the only thing that deletes them is a version commit. So "most recent bump-file deletion" is always the version commit for the versions being published, whether that's HEAD (the common case, unchanged behavior) or several commits back. No reliance on parsing
CHANGELOG.md.Known limitation
If two version cycles land before a publish (cycle A versions → publish partially fails → cycle B versions → publish runs), only cycle B's bump files are recovered; packages still pending from cycle A fall back to
No changelog entries.— same as today, not a regression. Downstream per-package filtering prevents any cross-contamination.Tests