chore: release-please uses gh app to authenticate

[adityachoudhari26]

Summary by CodeRabbit

• Chores
  • Switched workflow authentication to a GitHub App installation token for release operations.
  • Declared workflow outputs indicating whether a release was created and the release tag.
  • Passed the generated token into downstream release and image tagging steps to unify authentication.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: ed757fca-344f-465a-9995-0229f0e388a4

📥 Commits

Reviewing files that changed from the base of the PR and between 20b5db8 and 4643161.

📒 Files selected for processing (1)

• .github/workflows/release.yaml

Disabled knowledge base sources:

• Linear integration is disabled

You can enable these sources in your CodeRabbit configuration.

---

📝 Walkthrough

Walkthrough

The release workflow now generates a GitHub App installation token and uses it (via the step output) for release-please and image tagging, and the job exposes semantic-release outputs release_created and tag_name.

Changes

Release Workflow Authentication

Layer / File(s)	Summary
GitHub App token generation and workflow integration .github/workflows/release.yaml	A token generation step using actions/create-github-app-token@v2 is added; the release-please action and Tag Images step are updated to use the generated app token instead of secrets.GH_TOKEN. The job declares outputs proxying semantic-release outputs release_created and tag_name.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 I hopped in the CI where secrets once lay,
A fresh app token now guides the release way,
Tags spring like carrots, neat and on time,
Builds hum along in a tidy rhyme,
Hop, push, and deploy — a small dev's delight.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: updating the release-please workflow to use GitHub App authentication instead of a personal token.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch release-please-gh-app

---

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 and usage tips.}

[Copilot]

Pull request overview

This PR updates the GitHub Actions release workflow to authenticate release-please (and subsequent tagging steps) using a GitHub App installation token instead of a static personal/access token secret.

Changes:

• Add a step to generate a GitHub App token via actions/create-github-app-token@v2.
• Switch googleapis/release-please-action@v4 to use the generated App token.
• Switch the Tag Images step to use the generated App token via GITHUB_TOKEN.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

.github/workflows/release.yaml (1)

8-10: ⚠️ Potential issue | 🟠 Major

Restrict both GITHUB_TOKEN and GitHub App token scopes in release.yaml

• The workflow-level permissions grant contents: write and pull-requests: write, and the release job doesn’t override them—so the default GITHUB_TOKEN for this job is still writable.
• actions/create-github-app-token@v2 is created without any permission-* inputs, so the GitHub App token inherits the App installation’s full granted permissions.
• actions/checkout@v4 uses default persist-credentials: true, which can leave the writable GITHUB_TOKEN configured in git.

Harden by setting the release job’s permissions to the minimum needed for the default token (often read-only), set persist-credentials: false on checkout, and add explicit permission-* inputs to create-github-app-token@v2 for only the scopes required by release-please-action/tagging.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/release.yaml around lines 8 - 10, The workflow grants
broad repo token scopes at workflow level; update the release job to restrict
the default GITHUB_TOKEN to the minimum needed (e.g., set job-level permissions
to read-only like contents: read and only add write where strictly required),
set actions/checkout@v4 step to persist-credentials: false, and add explicit
permission-* inputs to actions/create-github-app-token@v2 to only request the
exact scopes used by release-please/tagging (reference the release job name, the
actions/checkout@v4 step, and actions/create-github-app-token@v2 to locate where
to apply these changes).

Source: Linters/SAST tools

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/release.yaml:
- Line 29: The workflow currently references third-party actions by floating
tags; update both actions (`actions/create-github-app-token@v2` and
`googleapis/release-please-action@v4`) to pin them to the exact commit SHAs you
trust by replacing the tag references with their corresponding commit SHA refs
(e.g., `actions/create-github-app-token@<commit-sha>` and
`googleapis/release-please-action@<commit-sha>`), ensuring you fetch the
upstream commit SHAs from the official repos and use those SHAs in the workflow.

---

Outside diff comments:
In @.github/workflows/release.yaml:
- Around line 8-10: The workflow grants broad repo token scopes at workflow
level; update the release job to restrict the default GITHUB_TOKEN to the
minimum needed (e.g., set job-level permissions to read-only like contents: read
and only add write where strictly required), set actions/checkout@v4 step to
persist-credentials: false, and add explicit permission-* inputs to
actions/create-github-app-token@v2 to only request the exact scopes used by
release-please/tagging (reference the release job name, the actions/checkout@v4
step, and actions/create-github-app-token@v2 to locate where to apply these
changes).

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 876b8399-52ba-4135-b7a4-fe76da60c3f1

📥 Commits

Reviewing files that changed from the base of the PR and between 1b6e0d9 and 20b5db8.

📒 Files selected for processing (1)

• .github/workflows/release.yaml

[coderabbitai]

⚠️ Potential issue | 🟠 Major

SHA-pin privileged actions in release workflow

.github/workflows/release.yaml mints a GitHub App token and uses it in the same job; the third-party actions are currently referenced by floating tags (not commit SHAs):

• actions/create-github-app-token@v2
• googleapis/release-please-action@v4

Pin both to the exact upstream commit SHAs you intend to trust.

🔒 Suggested fix

-        uses: actions/create-github-app-token@v2
+        uses: actions/create-github-app-token@<full-commit-sha>
...
-        uses: googleapis/release-please-action@v4
+        uses: googleapis/release-please-action@<full-commit-sha>

🧰 Tools

🪛 zizmor (1.25.2)

[error] 29-29: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)

---

[error] 29-29: dangerous use of GitHub App tokens (github-app): app token inherits blanket installation permissions

(github-app)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/release.yaml at line 29, The workflow currently references
third-party actions by floating tags; update both actions
(`actions/create-github-app-token@v2` and `googleapis/release-please-action@v4`)
to pin them to the exact commit SHAs you trust by replacing the tag references
with their corresponding commit SHA refs (e.g.,
`actions/create-github-app-token@<commit-sha>` and
`googleapis/release-please-action@<commit-sha>`), ensuring you fetch the
upstream commit SHAs from the official repos and use those SHAs in the workflow.