Skip to content

The "Full Changelog" link is incorrect when introducing tagpr for the first time. #389

Open

Description

@Songmu

Reference: #377

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.

Activity

  1. Songmu commented on Aug 25, 2026

    @Songmu
    OwnerAuthor

    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:

    1. For the first docs/ release, latestCalverTag() correctly returns an empty string because no previous docs/ tag exists.
    2. gh2changelog.Draft() therefore calls GenerateReleaseNotes with PreviousTagName: nil.
    3. 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.
    4. GitHub consequently generates v1.20.0...docs/2026.0823.0 as the Full Changelog link.
    5. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions