You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
The "Full Changelog" link is incorrect when introducing tagpr for the first time. #389
The detection of the immediately preceding tag used as the release comparison base is incorrect. The branch name is tagpr-from-docs-0.0.0, which is normal, but the comparison base tag is set to v1.20.0.
I investigated this and confirmed that the immediate cause is the default behavior of GitHub's Generate Release Notes API when tagpr creates the first release for a tag prefix.
The flow is:
For the first docs/ release, latestCalverTag() correctly returns an empty string because no previous docs/ tag exists.
gh2changelog.Draft() therefore calls GenerateReleaseNotes with PreviousTagName: nil.
When previous_tag_name is omitted, GitHub does not take the tag prefix into account. It automatically chooses the tag of the previous repository release, which was v1.20.0 in this case.
GitHub consequently generates v1.20.0...docs/2026.0823.0 as the Full Changelog link.
tagpr's replaceCompareLink() cannot correct it because it expects the generated comparison base to be the logical initial version, docs/0.0.0.
I also reproduced the API behavior directly:
Omitting previous_tag_name, or passing an empty string, produces a comparison from v1.20.0.
Passing the repository root commit SHA as previous_tag_name fails with HTTP 400 (Invalid previous_tag parameter); the API requires an existing tag.
Passing an existing prefixed tag such as docs/2026.0823.0 correctly produces a comparison from that tag.
This means subsequent releases under the same prefix work correctly; the problem is specific to the first release when the repository already has releases in another tag namespace.
A minimal fix would be to handle the no-previous-prefixed-tag case explicitly and replace GitHub's unrelated comparison link with a commits/<new tag or release branch> link. If we also want the generated release-note contents to cover the complete history rather than GitHub's automatically selected range, that requires a larger workaround, such as temporarily creating a tag at the intended starting commit, generating the notes, deleting the temporary tag, and rewriting the resulting link.
Activity
Songmu commentedon Aug 25, 2026
I investigated this and confirmed that the immediate cause is the default behavior of GitHub's Generate Release Notes API when tagpr creates the first release for a tag prefix.
The flow is:
docs/release,latestCalverTag()correctly returns an empty string because no previousdocs/tag exists.gh2changelog.Draft()therefore callsGenerateReleaseNoteswithPreviousTagName: nil.previous_tag_nameis omitted, GitHub does not take the tag prefix into account. It automatically chooses the tag of the previous repository release, which wasv1.20.0in this case.v1.20.0...docs/2026.0823.0as the Full Changelog link.replaceCompareLink()cannot correct it because it expects the generated comparison base to be the logical initial version,docs/0.0.0.I also reproduced the API behavior directly:
previous_tag_name, or passing an empty string, produces a comparison fromv1.20.0.previous_tag_namefails with HTTP 400 (Invalid previous_tag parameter); the API requires an existing tag.docs/2026.0823.0correctly produces a comparison from that tag.This means subsequent releases under the same prefix work correctly; the problem is specific to the first release when the repository already has releases in another tag namespace.
A minimal fix would be to handle the no-previous-prefixed-tag case explicitly and replace GitHub's unrelated comparison link with a
commits/<new tag or release branch>link. If we also want the generated release-note contents to cover the complete history rather than GitHub's automatically selected range, that requires a larger workaround, such as temporarily creating a tag at the intended starting commit, generating the notes, deleting the temporary tag, and rewriting the resulting link.