ci: stop using Release App token in release workflows#1866
Merged
TooTallNate merged 1 commit intomainfrom Apr 29, 2026
Merged
Conversation
The Release App has been temporarily removed. Switch the Release and Backport workflows to use the default GITHUB_TOKEN, and disable the cross-repo Front dispatch workflow until the App is restored. Also add a workflow_dispatch trigger to release.yml so the Version Packages PR can be created/updated manually (since pushes made by GITHUB_TOKEN do not trigger downstream workflow runs).
|
Contributor
Contributor
📊 Benchmark Results
workflow with no steps💻 Local Development
workflow with 1 step💻 Local Development
workflow with 10 sequential steps💻 Local Development
workflow with 25 sequential steps💻 Local Development
workflow with 50 sequential steps💻 Local Development
Promise.all with 10 concurrent steps💻 Local Development
Promise.all with 25 concurrent steps💻 Local Development
Promise.all with 50 concurrent steps💻 Local Development
Promise.race with 10 concurrent steps💻 Local Development
Promise.race with 25 concurrent steps💻 Local Development
Promise.race with 50 concurrent steps💻 Local Development
workflow with 10 sequential data payload steps (10KB)💻 Local Development
workflow with 25 sequential data payload steps (10KB)💻 Local Development
workflow with 50 sequential data payload steps (10KB)💻 Local Development
workflow with 10 concurrent data payload steps (10KB)💻 Local Development
workflow with 25 concurrent data payload steps (10KB)💻 Local Development
workflow with 50 concurrent data payload steps (10KB)💻 Local Development
Stream Benchmarks (includes TTFB metrics)workflow with stream💻 Local Development
stream pipeline with 5 transform steps (1MB)💻 Local Development
10 parallel streams (1MB each)💻 Local Development
fan-out fan-in 10 streams (1MB each)💻 Local Development
SummaryFastest Framework by WorldWinner determined by most benchmark wins
Fastest World by FrameworkWinner determined by most benchmark wins
Column Definitions
Worlds:
|
Contributor
🧪 E2E Test Results✅ All tests passed Summary
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
|
Contributor
There was a problem hiding this comment.
Pull request overview
Resumes release/backport automation by removing reliance on the (temporarily removed) Release GitHub App token and switching workflows to use the default GITHUB_TOKEN.
Changes:
- Update
release.ymlto useGITHUB_TOKENfor checkout/changesets/gh release, hardcode git identity, and addworkflow_dispatchfor manual releases. - Update
backport.ymlto remove App-token generation, useGITHUB_TOKEN, and raise job permissions to enable pushing/PR/commenting. - Disable the cross-repo dispatch workflow to
vercel/frontby gating jobs behind an always-false condition.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| .github/workflows/release.yml | Removes App-token dependency, uses GITHUB_TOKEN, adds manual dispatch trigger for releases. |
| .github/workflows/backport.yml | Removes App-token dependency, switches token usage to GITHUB_TOKEN, updates permissions for backport operations. |
| .github/workflows/dispatch-front-workflow-release-pr.yml | Temporarily disables cross-repo dispatch jobs (App-token still required) while documenting the reason. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
23
to
27
| if: > | ||
| false && | ||
| startsWith(github.event.pull_request.head.ref, 'changeset-release/') && | ||
| github.event.action != 'closed' | ||
| runs-on: ubuntu-latest |
There was a problem hiding this comment.
With the current if: false && ... gating, this workflow will still trigger on every matching pull_request event and create a run that immediately skips both jobs. If the intent is to fully disable it while the App is removed, consider disabling the triggers (e.g., temporarily switch on: to workflow_dispatch only, or comment out the pull_request trigger) to avoid noisy skipped runs and unnecessary Actions usage.
Contributor
karthikscale3
left a comment
karthikscale3
left a comment
There was a problem hiding this comment.
Concern: clean cherry-pick git push origin stable will likely fail under branch protection
Referring to:
# .github/workflows/backport.yml
- name: Push clean backport
if: steps.cherry-pick.outputs.status == 'clean'
run: git push origin stableThis is the most likely thing to break under this change, and it's the common (clean cherry-pick) path — not a rare one. With the App token gone, the push runs as the default GITHUB_TOKEN (GitHub Actions bot), and stable almost certainly has branch protection. If the protection has any of:
- "Restrict who can push to matching branches" (without explicitly allowlisting GitHub Actions),
- "Require status checks to pass before merging" (no checks will have run on the cherry-pick SHA — it's a direct push),
- "Require a pull request before merging",
…this push will be rejected and the workflow will fail. None of the existing Comment on … steps fire in that case (they're gated on cherry-pick.outputs.status == 'conflict', or on 'clean' with the push having succeeded), so backports would silently stop landing until someone notices the red runs.
The PR description's caveat #3 acknowledges the possibility, but the wording ("the AI-resolved-conflict path opens a PR instead, so that path should still work") understates the impact: the conflict path is the rare one. A clean cherry-pick is the typical case, and that path has no PR fallback.
Two options worth considering before merging:
- Verify that
stable's protection rules actually allow the defaultGITHUB_TOKENto push directly (e.g. GitHub Actions is in the bypass/allow list, or protection is disabled for bots). If yes, this is fine as-is — worth a confirmation note in the PR description. - If not, mirror the AI-resolved-conflict path for the clean case too: on push failure (or unconditionally), push the cherry-pick commit to a
backport/pr-<n>-to-stablebranch and open a PR viagh pr create --base stable. That path already works under branch protection (it's how the conflict path operates today), and it preserves the audit trail. The downside is one extra click per backport, which is a much smaller cost than silent backport drift.
karthikscale3
approved these changes
Apr 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The Release App has been temporarily removed, which currently blocks publishing new releases of the Workflow packages. This PR removes our reliance on the App token in the CI workflows so that releases can resume.
Changes
release.yml: Removed theGenerate GitHub App Tokenstep. Checkout, changesets, andgh releasecalls now use the defaultGITHUB_TOKEN. Git identity is hardcoded togithub-actions[bot]. Added aworkflow_dispatchtrigger so the Version Packages PR can be created/updated manually.backport.yml: Removed the App token step. Bumped job permissions fromcontents: readtocontents: write/pull-requests: write/issues: write(needed for pushing tostable, opening backport PRs, and commenting). Allgithub-tokenreferences switched to${{ secrets.GITHUB_TOKEN }}.dispatch-front-workflow-release-pr.yml: Disabled both jobs (if: false &&...) since cross-repo dispatch tovercel/frontrequires an App token. Re-enable when the App is restored.Caveats (pre-existing GitHub Actions behavior with
GITHUB_TOKEN)Pushes/PRs created by
GITHUB_TOKENdo not trigger downstream workflow runs. Implications:backport.ymllands onstable), theReleaseworkflow won't auto-run. Use the newworkflow_dispatchtrigger from the Actions tab to publish.stablehas branch protection that disallows pushes fromGITHUB_TOKEN, the backport's clean-cherry-pickgit push origin stablestep will fail. The AI-resolved-conflict path opens a PR instead, so that path should still work.