ci: use shared release-please caller workflow

[mark-brannan]

Summary

Replaces this repo's standalone .github/workflows/release-please.yml with a short caller that delegates to the shared reusable workflow extracted in mark-brannan/.github#37 (mark-brannan/.github/.github/workflows/release-please.yml@main).

wire-wright has no publish.yml workflow, so the caller passes publish: false — no publish dispatch to wire up here.

Test plan

• New file is valid YAML
• git diff --stat confirms only .github/workflows/release-please.yml changed, shrinking from ~72 to ~28 lines
• Confirm the workflow runs successfully on the next push to main (opens/updates the release PR as before)

🤖 Generated with Claude Code

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: 4d5a888b-c374-4074-8202-fb842f2e7ef4

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

Claude finished @mark-brannan's task in 2m 32s —— View job

---

Review complete

• Read CLAUDE.md / AGENTS.md — neither exists in this repo
• Review the diff
• Check referenced shared workflow (feat(workflows): add a reusable release-please workflow .github#37) — blocked, see note below
• Validate YAML / check for secrets
• Post findings

What I checked:

• git diff origin/main...HEAD on .github/workflows/release-please.yml (the only changed file)
• npm ci && npm test — 13/13 pass. Unrelated to this diff (workflow-only change) but confirms no incidental breakage.
• Visual inspection of the resulting YAML for structure/validity (couldn't run an automated linter — gh api, yamllint, and even multi-statement python3 -c all hit a sandbox approval gate this session can't clear non-interactively)
• Diffed against this repo's own conventions in pages.yml and test.yml
• Confirmed no credential-shaped strings landed in the diff — the two secrets.RELEASE_PLEASE_APP_* lines are references, not values

Findings (posted inline too):

1. actions: write is a new permission not present in the file it replaces (old file: contents: write, pull-requests: write only). Not obviously required now that publish: false is set. Worth a one-line justification comment (this file otherwise explains every permission/config choice) or dropping it if the callee doesn't need it.
2. The concurrency: {group: release-main, cancel-in-progress: false} block is dropped, with nothing replacing it. This repo's other push-to-main workflow (pages.yml) sets one explicitly, and a job calling a reusable workflow via uses: can still carry its own concurrency: key — so this looks like a real regression rather than dead weight the refactor correctly removed, unless the shared workflow sets an equivalent group internally (couldn't verify, see below).

Not a finding: the unpinned @main reference on the reusable workflow call is correct per this org's own convention for its own repos (fix-once semantics; third-party actions get pinned, mark-brannan/.github calls don't).

Verification gap, disclosed rather than papered over: this sandbox only has wire-wright attached — gh api/git clone/WebFetch against mark-brannan/.github all required approval that never arrives in this non-interactive run. So I could not confirm against the actual reusable workflow source: that publish is the right input name/type, that the two secret names match what it expects, or whether it defines its own concurrency guard (which would make finding #2 moot) or expects release-please-config.json/.release-please-manifest.json at these same root paths. Those are worth a human (or a session with that repo attached) checking against mark-brannan/.github#37 before merge.

Also attempted to post a top-level gh pr comment per instructions; this repo's public-issue-guard hook refused it (private-terms denylist file unreadable in this session — a known environment gap, not something this PR caused), so the full review is here instead.
· branch: release-please-caller

[claude]

actions: write is new — the workflow it replaces only carried contents: write and pull-requests: write. I can't reach mark-brannan/.github from this sandbox (repo isn't attached to this review session) to confirm the reusable workflow actually needs it. If it's required by the callee, fine, but it's worth a one-line comment saying why (mirrors the existing comment style in this file, which explains every other permission/config choice) rather than a bare addition — otherwise it reads as scope creep past least-privilege.

[claude]

The concurrency: {group: release-main, cancel-in-progress: false} block from the old file is dropped, with nothing replacing it here. Every other push-to-main workflow in this repo sets one explicitly at the call site (pages.yml has group: pages), so this is a departure from local convention, not just a line count reduction.

A job that calls a reusable workflow via uses: can still carry its own concurrency: key:

jobs:
  release:
    concurrency:
      group: release-main
      cancel-in-progress: false
    uses: mark-brannan/.github/.github/workflows/release-please.yml@main

Worth doing unless the shared workflow itself sets an equivalent concurrency group internally — I couldn't verify that from here since the .github repo isn't attached to this sandbox. Two rapid pushes to main without some concurrency guard risk overlapping release-please runs racing on the manifest/release PR.

Fix this →