--generate-notes uses the commit graph, not semver ordering#61
Conversation
|
/describe |
|
✅ PR description has been generated and updated! |
![docker-agent[bot]](https://avatars.githubusercontent.com/in/2787757?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Summary
This PR improves the release notes generation by explicitly specifying the previous tag using --notes-start-tag. The implementation is well-structured and follows bash best practices:
✅ Correct array handling: ARGS=() declaration and "${ARGS[@]}" expansion are proper
✅ Safe conditional logic: [ -n "$PREVIOUS" ] correctly checks for non-empty values
✅ Proper quoting: Variables are quoted to prevent word splitting
✅ Fallback handling: The conditional ensures the flag is only added when a previous tag exists
No issues found. This change looks good!
derekmisler
force-pushed
the
release-notes-were-using-the-commit-graph-not-sem
branch
from
358962b to
745671b
Compare
derekmisler
force-pushed
the
release-notes-were-using-the-commit-graph-not-sem
branch
from
745671b to
e8affa4
Compare
derekmisler
force-pushed
the
release-notes-were-using-the-commit-graph-not-sem
branch
from
e8affa4 to
c8a943e
Compare
Signed-off-by: Derek Misler <derek.misler@docker.com>
derekmisler
force-pushed
the
release-notes-were-using-the-commit-graph-not-sem
branch
from
c8a943e to
9b04200
Compare
| jobs: | ||
| review: | ||
| if: github.event.issue.pull_request && contains(github.event.comment.body, '/review') | ||
| if: github.event.issue.pull_request && startsWith(github.event.comment.body, '/review') |
There was a problem hiding this comment.
honestly this was kinda nice, but not sure if it was problematic.
There was a problem hiding this comment.
yeah, the /help command in Pinata listed all the commands available, which included the review command, and it was running reviews that would fail because they were triggered by bots without an author association. and then every time i would explain that to someone in a PR, I would inevitably include that review command in my explanation, which triggered another review
2 participants
Summary
GitHub's
--generate-notesflag determines the range of commits to include in release notes by walking the commit graph from the new tag back to the previous reachable tag — it does not use semver ordering. This means if tags exist out of semver order in the graph, the generated notes can be incorrect or empty. This PR explicitly passes--notes-start-tagwith the previously detected tag so the release note range is always correct and predictable.Changes
.github/workflows/release.yml: Captures the previously detected tag (LATEST_TAG) as a step output (previous), then conditionally passes--notes-start-tag "$PREVIOUS"togh release createwhen a previous tag exists, ensuring release notes always cover exactly the commits since the last release.How to Test
New version: X.Y.Z (previous: vA.B.C)line to confirm the previous tag is being detected and passed through correctly.--notes-start-tagargument is omitted whenPREVIOUSis empty.