ci(release-plz): add workflow_dispatch trigger to release-plz PR workflow

[pvandervelde]

Problem

The release-plz PR workflow only triggers on \push\ to master. When a branch is deleted before the push-triggered run completes (or the run is missed), there is no way to manually re-trigger it.

Fix

Add \workflow_dispatch: {}\ so the workflow can be triggered manually from the GitHub Actions UI.

Usage After Merge

Go to Actions → Release-plz PR → Run workflow to manually kick off a new release-plz PR.

[claude]

Claude finished @pvandervelde's task in 52s —— View job

---

PR Review

• Gather context
• Read CLAUDE.md for repo guidelines (no CLAUDE.md present)
• Read changed workflow file
• Analyze change and provide review feedback

---

Summary

This is a minimal, well-scoped change that adds manual trigger capability to the release-plz-pr workflow. The implementation is correct.

Change Analysis

File: .github/workflows/release-plz-pr.yml line 7

workflow_dispatch: {}

Correctness ✅
workflow_dispatch: {} is valid YAML and the correct syntax for enabling manual triggers with no custom inputs. Placement in the on: block alongside the existing push trigger is appropriate.

Concurrency behavior ✅
The concurrency group key is release-plz-pr-${{ github.ref }}. When triggered via workflow_dispatch, GitHub defaults github.ref to refs/heads/master (the repository's default branch), so manually-triggered runs will land in the same concurrency group as push-triggered runs. With cancel-in-progress: false, queued runs won't stomp on each other — correct behavior for release-plz.

Idempotency ✅
The release-pr command is idempotent: it updates an existing release PR if one is open, or creates a new one if none exists. Manual re-triggering is safe with no risk of duplicate PRs.

Security ✅
workflow_dispatch requires at minimum write access to the repository to invoke, consistent with the permissions already required by this workflow (contents: write, pull-requests: write). No privilege escalation risk.

Consistency with sibling workflow ✅
The companion release-plz.yml (release publishing) triggers on pull_request: closed, which doesn't benefit from workflow_dispatch in the same way. That workflow has a guard condition (merged == true && label == 'release') that makes manual dispatch less meaningful — so the asymmetry is intentional and correct.

Minor Nit (non-blocking)

workflow_dispatch: {} and workflow_dispatch: (bare) are equivalent YAML. The explicit {} is arguably more readable as it signals "intentionally empty config" rather than an accidental omission. No change needed.

---

Verdict: LGTM. The change is correct, minimal, and addresses a real operational gap. No issues found.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 50.18%. Comparing base (ba88add) to head (bc7f632).
⚠️ Report is 2 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master      #32   +/-   ##
=======================================
  Coverage   50.18%   50.18%           
=======================================
  Files          10       10           
  Lines        3553     3553           
  Branches     3553     3553           
=======================================
  Hits         1783     1783           
  Misses       1720     1720           
  Partials       50       50           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.