Skip to content

ci: give the release-notes job full git history - #250

Merged
oratis merged 1 commit into
mainfrom
fix/release-notes-history
Aug 8, 2026
Merged

ci: give the release-notes job full git history#250
oratis merged 1 commit into
mainfrom
fix/release-notes-history

Conversation

@oratis

@oratis oratis commented Aug 8, 2026

Copy link
Copy Markdown
Owner

Summary

v0.3.0 shipped with an empty release body — it reads 0 commits. where nine PRs of work should be listed.

actions/checkout is shallow by default. The single fetched commit therefore has no parents, so:

FROM=$(git rev-list --max-parents=0 HEAD)   # returns HEAD itself, not the root commit
npx tsx scripts/gen-release-notes.ts "$FROM" HEAD

…walks an empty range.

Only github-release reads history, so only that checkout gets fetch-depth: 0. The other four stay shallow.

Why a manual check missed it

I ran gen-release-notes.ts locally before the tag and it produced correct, well-grouped output — because a local clone has full history. The script was never the problem; its input was. Worth recording, because "I tested the script" is exactly the check that doesn't catch this.

Follow-up

The published v0.3.0 body needs regenerating — I'll do that with gh release edit once this merges, so the existing release stops under-reporting what's in it.

Test plan

  • Reproduced the mechanism: git rev-list --max-parents=0 HEAD returns HEAD in a shallow clone, giving an empty range
  • Confirmed the generator itself is fine — full-history run lists all nine governance PRs grouped by type
  • Verified by the next tag run, and by the regenerated v0.3.0 body

Release notes label

  • release-notes:internal

Related

Fifth release.yml defect surfaced by the first real release. Follows #246, #247, #248, #249.

🤖 Generated with Claude Code

v0.3.0 shipped with a release body reading "0 commits."

actions/checkout is shallow by default, so the fetched commit has no parents
and `git rev-list --max-parents=0 HEAD` returns HEAD itself. The range is then
empty and gen-release-notes has nothing to walk. It looks correct when run
locally, where the clone is complete — which is why this passed a manual check
before the tag.

Only the github-release job reads history; the other four checkouts stay shallow.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@oratis
oratis merged commit a8274ef into main Aug 8, 2026
5 checks passed
@oratis
oratis deleted the fix/release-notes-history branch August 8, 2026 14:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant