Drop release-body parsing; use GitHub commit-range and generate-notes for PRs - #4092
Conversation
Replace all ReleaseNoteParser / release-body parsing in the gh-release and profile github_release flows with IGitHubCommitRangeService. The GitHub compare API is the authoritative source of PRs for a release; the release body text was fragile (empty bodies, varying formats) and has been removed entirely. Each PR decision is now logged explicitly: why it was included or excluded. Update GhReleaseExtractionParityTests, ReleaseVersionTests, BundleProfileGitHubReleaseTests, and BundleCdnSourcingTests to mock FetchReleasesAsync and ResolvePullRequestsAsync instead of body text. Co-Authored-By: Claude <noreply@anthropic.com>
Docs preview (local build)Handbook preview: https://docs-v3-preview.elastic.dev/elastic/docs-builder/pull/4092/ |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Requesting changes: the new commit-range flow can fail for valid older release tags because predecessor lookup is limited to the latest 10 releases.
What is this? | From workflow: PR Review
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
Co-Authored-By: Claude <noreply@anthropic.com>
Replaces the FetchReleasesAsync + SkipWhile approach with a POST to
/repos/{owner}/{repo}/releases/generate-notes, which returns
previous_tag_name directly from GitHub's own algorithm. This handles
multi-version repos correctly — GitHub picks the right predecessor even
when releases are interleaved across major versions.
Co-Authored-By: Claude <noreply@anthropic.com>
Mpdreamz
changed the title
There was a problem hiding this comment.
Requesting changes: previous-tag resolution in the --release-version path should not rely on a fixed 10-release window.
What is this? | From workflow: PR Review
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
The bundle --release-version and remove --release-version flows in ChangelogCommand.cs still used the 10-release FetchReleasesAsync + SkipWhile pattern. Switch them to FetchPreviousTagAsync so all call sites use the generate-notes endpoint consistently. Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
Requesting changes based on the inline findings.
What is this? | From workflow: PR Review
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
Use a typed DTO serialized via the AOT JSON context for the generate-notes request body instead of raw string interpolation, so tag names with special characters are always encoded correctly. Split resolution==null (API/credential failure → error, return 1) from resolution.PullRequests.Count==0 (valid empty range → warning, return 0) in the bundle and remove --release-version flows so real failures are not silently swallowed as no-ops. Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
Requesting changes based on the inline findings.
What is this? | From workflow: PR Review
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
…leFilterResolver ChangelogRemoveService now accepts IGitHubCommitRangeService and passes it to ProfileFilterResolver.ResolveAsync, so source: github_release profiles work in changelog remove instead of failing with a null-service error. ProfileFilterResolver now distinguishes resolution==null (API/credential failure → error) from PullRequests.Count==0 (valid empty range → warning) so failures are not masked as no-op warnings. Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
Approving — no new actionable issues found in the latest changes.
What is this? | From workflow: PR Review
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
2 participants
Fixes the tagged-workflow bundle failure on repos with an empty release body by replacing two unreliable approaches with the GitHub APIs that own those answers.
Affects: Changelog pipeline, GitHub Actions integration
Prompt summary: The tagged workflow on
elastic/docs-playground-release-notes-taggedfailed because the release body was empty — the old code tried to parse PR references out of the body markdown. The user asked to remove all body-parsing logic entirely and use only the GitHub API's own PR list and commit-range API as the source of truth, with verbose per-PR decision output. A follow-up improvement usesPOST /releases/generate-notesto find the previous tag instead of fetching the last N releases and scanning.Why
ReleaseNoteParser.Parse("")returned format=Unknown with 0 PRs, causing an early return with no changelogs. Body format varies across repos and tools — relying on it is fragile. The GitHub compare API ({prevTag}..{currentTag}) already returns the authoritative PR list; it needs no body. The previous-tag discovery fetched the last 10 releases and scanned with SkipWhile, which breaks for multi-version repos where releases are interleaved across major versions.What
Release-body parsing removed
ReleaseNoteParseris no longer called from any production path.GitHubReleaseChangelogServiceandProfileFilterResolvernow callIGitHubCommitRangeService.ResolvePullRequestsAsyncdirectly to get the PR list from the commit range between the previous and current tags.Previous-tag discovery via
generate-notesIGitHubReleaseService.FetchPreviousTagAsynccallsPOST /repos/{owner}/{repo}/releases/generate-noteswith{"tag_name": "<currentTag>"}. GitHub returnsprevious_tag_nameusing its own algorithm, which handles interleaved multi-version releases correctly. No side effects — the endpoint only generates content.Verbose per-PR decision logging
Each PR from the commit range is logged with its inclusion or exclusion reason (matched label block rule, label-derived type, pool entry used, or PR info unavailable).
CLI schema updated
warn-on-type-mismatchflag removed fromdocs/cli-schema.jsonafter the corresponding code was deleted.Verify
dotnet test tests/Elastic.Changelog.Tests/