fix: grant pull-requests write permission in release workflow

[ericcrosson-bitgo]

Problem

The release workflow has been failing at the very last step — after the tag and GitHub release are already successfully created — with a 404 from the GitHub API.

Failing run: https://github.com/BitGo/semantic-release-github-actions/actions/runs/25228201691/job/73976939543

What goes wrong

@semantic-release/github runs a success step after publishing the release. It parses all commit messages in the release, extracts PR numbers from merge commit messages (e.g. Merge pull request #41 from ...), and posts a comment on each PR. That requires pull_requests=read at minimum — the API response even tells us:

x-accepted-github-permissions: pull_requests=read

The failing request:

GET /repos/BitGo/semantic-release-github-actions/pulls/41/commits
→ 404 Not Found

PR semantic-release-action#41 doesn't exist in this fork. It exists in the upstream semantic-release-action/github-actions repo. The fork inherited upstream commit history, including merge commit messages that reference upstream PR numbers. When @semantic-release/github tries to look them up here, it gets 404 and throws, failing the job.

Why there was no explicit permissions block

The workflow has no permissions: declaration, so it inherits the repository default. For org repos with restricted default token permissions, pull-requests is not granted, causing the 404.

Fix

Add an explicit permissions block to the release job:

permissions:
  contents: write       # create git tags and GitHub releases
  issues: write         # post issue comments (semantic-release success step)
  pull-requests: write  # post PR comments (semantic-release success step)

contents: write was already implicitly needed (tag + release creation was working), but making it explicit is correct practice. issues: write and pull-requests: write are what @semantic-release/github needs to comment on issues and PRs after a release.

Why not just disable PR comments?

An alternative would be setting successComment: false in .releaserc.json. That would also stop the crash, but it silently degrades functionality — downstream repos that use this action and have valid PRs would lose release comments. Granting the permission is the right fix: it restores the intended behavior rather than working around missing access.

Verification

After merging, the next push to master should produce a release run that completes all steps including success without a 404. The full expected log sequence ends with:

✔  Completed step "success" of plugin "@semantic-release/github"
✔  Run automated release from branch master

Checklist

• Root cause identified (missing pull-requests permission on GITHUB_TOKEN)
• Fix is minimal — 4 lines added, no behavioral changes
• .releaserc.json unchanged — no features disabled
• Permissions follow least-surprise: explicit rather than inherited

Ticket: DX-916

[linear-code]

DX-916 Debug semantic-release-github-actions release workflow failure