ci: run release-please via CLI instead of the googleapis action

[max-parke-scale]

What

Rewrites the release-please workflow (added in #321) to run the release-please CLI under actions/setup-node, instead of googleapis/release-please-action.

Why

After #321 merged, the workflow failed at startup on every push to main (startup_failure, no logs, no release PR cut). The merged YAML is valid and the action SHA resolves — the cause is the org Actions allow-list: googleapis/release-please-action isn't on it. (Every other workflow here uses only actions/, astral-sh/, docker/, stainless-api/, codecov/, dorny/; the Actions-policy API is admin-only/403 for me, so I couldn't read it directly, but the signature is unambiguous.)

Fix

Run npx release-please@16 release-pr + github-release (manifest mode — same as the action did internally) under actions/setup-node@v4, which is allow-listed (actions/* is used throughout the repo). No third-party action → allow-list-proof.

Verified the CLI commands (release-pr/github-release; manifest-pr/manifest-release are deprecated aliases) and flags (--token, --repo-url, --config-file, --manifest-file) against release-please@16.

After merge

Runs on main; once a feat/fix lands (or via workflow_dispatch) it opens the first release PR → merging that cuts the first vX.Y.Z tag. Config + manifest are unchanged from #321.

🧑‍💻🤖 — posted via Claude Code

Greptile Summary

• Replaces the blocked googleapis/release-please-action workflow step with direct release-please@16 CLI commands.
• Sets up Node 20 through actions/setup-node@v4 before running release PR and GitHub release commands.
• Keeps the existing release-please config and manifest files while adding issues: write for label management.

Confidence Score: 5/5

The workflow change is narrowly scoped to replacing a blocked GitHub Action with equivalent CLI invocations.

Only one CI workflow file changed, the release-please config and manifest remain unchanged, and no code issues were identified.

T-Rex Logs

What T-Rex did

• The T-Rex run performed a pre-artifact check by inspecting the base release-please CLI workflow using git show and grep probes.
• The T-Rex run performed a post-artifact validation that included a second git show, YAML parse success, workflow contract probes, referenced file checks, and the release-please@16 CLI version/help output.
• The T-Rex run confirmed the overall step completed with FINAL_EXIT_CODE: 0.

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

1. .github/workflows/release-please.yml, line 12-14 (link)

   Grant label permissions

   The CLI still applies and removes release-please labels on release PRs, and those calls go through GitHub's Issues API. This workflow only grants contents: write and pull-requests: write, so the job can fail with a permissions error when it tries to add or remove labels like autorelease: pending. Add issues: write here so the CLI has the same label permissions the release flow needs.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: .github/workflows/release-please.yml
   Line: 12-14
   
   Comment:
   **Grant label permissions**
   
   The CLI still applies and removes release-please labels on release PRs, and those calls go through GitHub's Issues API. This workflow only grants `contents: write` and `pull-requests: write`, so the job can fail with a permissions error when it tries to add or remove labels like `autorelease: pending`. Add `issues: write` here so the CLI has the same label permissions the release flow needs.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

_{Reviews (2): Last reviewed commit: "ci: run release-please via CLI instead o..." | Re-trigger Greptile}