Repository navigation
Write an already-released version's changelog entry once - #231
Merged
Merged
Conversation
When the pipeline runs on a HEAD that is already tagged (the daily schedule or a manual dispatch with nothing new), the version to write is the tag at the top of the history. GenerateAsync wrote a "no significant changes" stub for it, diffed from the tag to itself, and then the history wrote the real entry for the same tag underneath. LATEST_CHANGELOG.md got the stub. When the current version's tag already exists, the history alone renders it now, and LATEST_CHANGELOG.md takes that tag's real entry. The regenerated files then match what is committed, so a scheduled run on a released HEAD leaves the tree clean and makes no metadata commit. Fixes #160 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TJeQu4i8WTCDpvC4TN4Rjw
|
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.
Fixes #160
Before
On a HEAD that is already tagged, such as the daily schedule or a manual dispatch with nothing new since the release,
ChangelogGenerator.GenerateAsyncwrote the version twice. First came a "no significant changes" stub, diffed from the tag to itself. Then the history wrote the real entry for the same tag.LATEST_CHANGELOG.mdended up holding only the stub.After
When
v{version}is already in the tag list, there is no separate current-version entry. The history renders that version once, from its tag, andLATEST_CHANGELOG.mdtakes that tag's real entry. The rest is unchanged: the per-tag body of the historical loop moved intoGetTagNotesAsyncso both paths share it.Because the regenerated files now match what is committed, a scheduled run on a released HEAD leaves the working tree clean, and
MetadataServicealready skips the commit when nothing is staged.Not done: part 2 of the issue (skip metadata on a
Skipincrement)In
ci,UpdateMetadataAsyncruns beforeResolveVersionAsync. TheSkipdecision is made against the metadata commit, so it doesn't exist yet when metadata is generated. Skipping generation would also leave the workspace withoutVERSION.mdonce consumer repositories gitignore it, as .github#6 decides, and the build reads its version from that file. With part 1 in, regenerating on a released HEAD is a no-op, so the gate would add an ordering change without stopping any additional commit. I'm happy to follow up if you still want it.Testing
GenerateAsync_VersionAlreadyTagged_WritesItsEntryOnceWithItsRealNotes: exactly one## v1.0.1heading, no "no significant changes" text, andLATEST_CHANGELOG.mdholds v1.0.1's real notes. It fails onmain(2 headings) and passes with the fix.🤖 Generated with Claude Code
https://claude.ai/code/session_01TJeQu4i8WTCDpvC4TN4Rjw
Generated by Claude Code