ci: use workflow token for production markers

[borgesius]

Summary

• remove the release GitHub App token requirement from benchmarks web production release
• remove the same token requirement from the runner/API production marker step
• use the workflow's built-in contents:write token for marker branch pushes

Validation

• actionlint .github/workflows/web-release.yml .github/workflows/runner-release.yml

This unblocks marker branch creation in repos where RELEASE_APP_ID / RELEASE_APP_PRIVATE_KEY are intentionally not configured.

Greptile Summary

This PR removes the dependency on the RELEASE_APP_ID / RELEASE_APP_PRIVATE_KEY GitHub App secrets from the production marker steps in both the runner and web release workflows, replacing the App-generated token with the built-in GITHUB_TOKEN (which already has contents: write granted at the workflow/job level).

• Drops the actions/create-github-app-token step and the explicit token: parameter from actions/checkout in both promote_marker (runner) and promote (web) jobs — the credential stored by actions/checkout's default persist-credentials: true is now used for the subsequent git push.
• No other workflows in the repository listen on production-runner or production-web branches, so the behavioral difference that GITHUB_TOKEN pushes do not trigger on: push events has no current impact.
• Whether GITHUB_TOKEN can push to these branches depends on whether they carry branch protection rules; if they do, the repository settings must allow GitHub Actions to bypass those rules.

Confidence Score: 4/5

Safe to merge if the production marker branches are unprotected or the repo already permits GitHub Actions to push to them; worth confirming branch protection configuration before landing.

The change is a clean removal of two symmetric App-token steps, the necessary contents:write permission is already in place, and no other workflows in the repo react to pushes on these marker branches. The one open question is whether production-runner / production-web carry branch protection rules that the GitHub App token was previously bypassing — if so, the push step will start failing with the workflow token too.

Both workflow files are straightforward; the only thing worth double-checking is the branch protection configuration for the production-runner and production-web branches in the repository settings.

Important Files Changed

Filename	Overview
.github/workflows/runner-release.yml	Removes GitHub App token generation from the promote_marker job; the job already carries contents:write and checkout defaults persist-credentials to true, so git push uses GITHUB_TOKEN directly.
.github/workflows/web-release.yml	Removes GitHub App token generation from the promote job; workflow-level contents:write and default persist-credentials allow the git push to production-web to proceed with GITHUB_TOKEN.

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant WF as Workflow (GITHUB_TOKEN)
    participant GH as GitHub API
    participant Repo as Repository

    Note over WF: Before: App token required
    WF->>GH: actions/create-github-app-token (RELEASE_APP_ID + RELEASE_APP_PRIVATE_KEY)
    GH-->>WF: App token
    WF->>Repo: checkout (token: app_token)
    WF->>Repo: "git push HEAD:refs/heads/production-*"

    Note over WF: After: Workflow token only
    WF->>Repo: checkout (implicit GITHUB_TOKEN, persist-credentials: true)
    WF->>Repo: "git push HEAD:refs/heads/production-*"
    Note over WF,Repo: contents:write permission granted at workflow/job level

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant WF as Workflow (GITHUB_TOKEN)
    participant GH as GitHub API
    participant Repo as Repository

    Note over WF: Before: App token required
    WF->>GH: actions/create-github-app-token (RELEASE_APP_ID + RELEASE_APP_PRIVATE_KEY)
    GH-->>WF: App token
    WF->>Repo: checkout (token: app_token)
    WF->>Repo: "git push HEAD:refs/heads/production-*"

    Note over WF: After: Workflow token only
    WF->>Repo: checkout (implicit GITHUB_TOKEN, persist-credentials: true)
    WF->>Repo: "git push HEAD:refs/heads/production-*"
    Note over WF,Repo: contents:write permission granted at workflow/job level

Loading

Comments Outside Diff (1)

1. .github/workflows/runner-release.yml, line 238-241 (link)

   GITHUB_TOKEN cannot bypass branch protection rules

   If production-runner (or production-web in the web workflow) is a protected branch, this git push will fail with a 403 unless the repository settings explicitly allow GitHub Actions to bypass those protections. A GitHub App token used previously could be configured to bypass protections via the app's installation permissions. If these marker branches are unprotected, this is fine as-is; but if branch protection was part of why the App token was originally introduced, the push will still fail — just with a different error than "missing secrets".

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

_{Reviews (1): Last reviewed commit: "ci: use workflow token for production ma..." | Re-trigger Greptile}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
benchmarks	Ready	Preview, Comment	Jun 19, 2026 12:59am

[coderabbitai]

Warning

Review limit reached

@borgesius, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 4 minutes and 55 seconds. Learn how PR review limits work.

To continue reviewing without waiting, enable usage-based billing in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 807d25fb-0bcb-42c1-8c97-857507b4c1bc

📥 Commits

Reviewing files that changed from the base of the PR and between 4f46991 and 8650003.

📒 Files selected for processing (2)

• .github/workflows/runner-release.yml
• .github/workflows/web-release.yml

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/release-token-hotfix

---

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