ci: publish GitHub release notes from the proposal PR

[IlyasShabi]

What does this PR do?:

Publishes a GitHub Release for every version cut from a v5.x release branch, using the release proposal PR's body as the release notes.

Two changes to the publish_release job in .github/workflows/release.yml:

• New Release notes step. Resolves the proposal PR by its head branch (v$VERSION-proposal) and creates the release from its body — or edits the release if it already exists.
• Tag release is now idempotent. Guarded with git ls-remote --tags, so a rerun after a partial failure can repair the tag and the notes instead of failing on "tag already exists".

Motivation:

The releases page is empty. The job pushes a git tag but never creates a release, so all 58 tags render with no notes — even though every release since v1.0.0 already has a proposal PR with a written changelog. Consumers have no changelog to read, and nothing to subscribe to for release notifications.

This ports the mechanism dd-trace-js uses, where scripts/release/notes.js runs as the last step of the publish job. Kept as inline shell rather than a script since pprof-nodejs has a single release line and needs none of the --latest/dist-tag arbitration that script does.

Additional Notes:

• Lookup is by head branch, not commit SHA. gh pr view v5.19.0-proposal resolves from package.json alone, and still works after the branch is deleted on merge (the PR record keeps headRefName). Verified against v5.19.0 #409, whose branch is already gone.
• No permission changes. self.github.release.push-tags.sts.yaml already grants contents: write, which covers release creation. dd-trace-js makes the same gh pr view call under a byte-identical policy, so the pulls read is expected to work; if it 401s on the first run, the fix is adding pull-requests: read there.
• --latest is hardcoded because v5.x is the only release line — main is 6.0.0-pre and unreleased. Noted in a comment: once a second line ships, this has to be decided per branch the way dd-trace-js does it.
• Takes effect on the release that carries it. For push events GitHub uses the workflow file from the pushed commit, so once this is cherry-picked onto v5.x by the next release proposal, that same release gets notes.
• Backfilling the existing 58 tags is deliberately not in this PR — it will follow once this is approved.

How to test the change?:

Not feasible to test in CI without publishing a release, so every command in both steps was dry-run against the live repo, read-only:

Check	Result
gh pr view v5.19.0-proposal --json body	exit 0, 121 bytes, byte-identical to #409's body
gh release view v5.19.0	exit 1 → takes the create branch
git ls-remote --tags guard, v5.19.0 vs v5.99.0	exists (skip) / absent (tag+push)
--target / --title / --latest / -F on create + edit	all supported
Body resolution across all 58 tags	51 resolve to a proposal PR, 38 with a non-empty body

The notes were also rendered through GitHub's GFM API with repo context to confirm the #NNN references auto-link. For v5.19.0 the release page would show:

New features
  • #401
  • #404
Improvements
  • #402  • #403  • #407  • #408
Other (build, dev)
  • #405  • #406

Worth noting separately: that body is a bare number list, so the rendered notes carry no titles. v5.18.0 (#394) used [title](commit) #NNN entries and reads much better. This PR only moves the body onto the releases page — improving what proposals put in the body is a follow-up.

[github-actions]

Overall package size

Self size: 2.62 MB
Deduped: 3.32 MB
No deduping: 3.32 MB

Dependency sizes

| name | version | self size | total size | |------|---------|-----------|------------| | pprof-format | 2.3.1 | 504.33 kB | 504.33 kB | | source-map | 0.8.0 | 185.66 kB | 185.66 kB | | node-gyp-build | 4.8.4 | 13.86 kB | 13.86 kB |

_{🤖 This report was automatically generated by heaviest-objects-in-the-universe}

[szegedi]

Nice!