ci: use client-id instead of deprecated app-id for app tokens - #1784
Merged
Conversation
actions/create-github-app-token deprecated the 'app-id' input in favour of 'client-id', which emitted a warning on every 'Generate token' step. release-tag.yml already used 'client-id' with the existing GH_APP_CLIENT_ID repository variable, so the remaining workflows now follow the same pattern and the APP_ID secret is no longer referenced anywhere.
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 4 included reviews per hour; 2 remain after this review. 📝 WalkthroughWalkthroughThree GitHub Actions workflows now source the GitHub App client ID from the ChangesGitHub App token configuration
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to This PR replaces a deprecated GitHub App token input with the existing client ID variable in three workflows without changing token-generation behavior; no actionable merge-blocking risk remains after normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (3 skipped: 3 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
spydon
added a commit
to supabase/sdk
that referenced
this pull request
Aug 28, 2026
## What
Replace the deprecated `app-id` input of
`actions/create-github-app-token` with `client-id`.
- `release.yml`: the `release-please` job now reads the Supabase
Releaser client ID from a new `GH_APP_CLIENT_ID` repository variable
(already created) instead of `secrets.APP_ID`.
- `sync-sdk-compliance.yml`: drops the optional `app-id` secret input
and makes `client-id` required.
## Why
Every `Generate token` step logged, twice (once for the main step, once
for the post step):
```
##[warning]Input 'app-id' has been deprecated with message: Use 'client-id' instead.
```
The action declares `deprecationMessage` on `app-id`, so the warning
fires whenever the key is present in `with`, regardless of value. In the
reusable workflow that meant the warning appeared even for callers that
only passed `client-id`, because `app-id: ${{ secrets.app-id }}` was
still listed.
Internally the action does `core.getInput("client-id") ||
core.getInput("app-id")` and passes the result straight through as the
JWT issuer, so the two inputs are interchangeable apart from the
warning.
Client IDs are public app metadata (`GET /apps/supabase-releaser`), so a
repository variable is a better fit than a secret.
## Breaking change
`sync-sdk-compliance.yml` no longer accepts an `app-id` secret. Callers
pinned to earlier SHAs are unaffected. Callers bumping past this
revision must pass `client-id`:
- `supabase/supabase-js` already passes `client-id`.
- `supabase/supabase-flutter` is updated in
supabase/supabase-flutter#1784.
- `supabase/supabase-swift` still passes `app-id` and is pinned to
`v1.0.0`, so it needs updating before its next bump.
## Test plan
- No behaviour change to token generation; the same app and private key
are used.
- Verified `GH_APP_CLIENT_ID` matches the `supabase-releaser` app that
authors the release pull requests.
grdsdev
approved these changes
Aug 31, 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
2 participants
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.
What
Replace the deprecated
app-idinput ofactions/create-github-app-tokenwithclient-idin the three workflows that still used it:release-prepare.ymlrelease-publish.ymlsync-compliance.yml(forwarded as theclient-idsecret to the reusable workflow, which already accepts it at the pinnedv1.5.0)All three now use the existing
vars.GH_APP_CLIENT_IDrepository variable, the same patternrelease-tag.ymlalready uses. TheAPP_IDsecret is no longer referenced anywhere.Why
Every
Generate tokenstep logged, twice (once for the main step, once for the post step):The action declares
deprecationMessageonapp-id, so the warning fires whenever the key is present inwith. Internally it doescore.getInput("client-id") || core.getInput("app-id")and passes the result straight through as the JWT issuer, so the two inputs are interchangeable apart from the warning.Test plan
secrets.PRIVATE_KEYis untouched andGH_APP_CLIENT_IDis the client ID of the same app.release-tag.ymlhas not had a non-skipped run since it switched toclient-id, so the first release cycle after this merges is the real exercise of the variable.Summary by CodeRabbit