chore(ci): pin supabase cli version explicitly#142
Open
chiptus wants to merge 20 commits into
Open
Conversation
Bump supabase devDependency to 2.109.1 and pin the same version explicitly in the setup-cli step of both the db-migrate and deploy-edge-functions workflows, since the action's auto-detect from package.json has proven unreliable. Closes #33
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Deploy →
|
There was a problem hiding this comment.
Pull request overview
This PR updates the project’s Supabase CLI version and ensures GitHub Actions deploy workflows use a deterministic CLI install, avoiding the previously observed unreliable “auto-detect” resolution behavior.
Changes:
- Bump the
supabasenpm dependency from2.58.5to2.109.1(and updatepnpm-lock.yamlaccordingly). - Pin
supabase/setup-cli@v2to install Supabase CLI2.109.1explicitly in the DB migrate and edge function deploy workflows.
Reviewed changes
Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
package.json |
Updates the Supabase CLI dependency version. |
pnpm-lock.yaml |
Locks the dependency graph to Supabase CLI 2.109.1 and related transitive updates. |
.github/workflows/_db_migrate.yml |
Pins supabase/setup-cli to install CLI 2.109.1 for migrations. |
.github/workflows/_deploy_edge_functions.yml |
Pins supabase/setup-cli to install CLI 2.109.1 for function deploys. |
Files not reviewed (1)
- pnpm-lock.yaml: Generated file
^2.109.1 still let local installs drift across the 2.x range, defeating the point of an explicit pin. Match the exact version used in CI.
chiptus
commented
Jul 10, 2026
v3 reads the supabase package version from pnpm-lock.yaml directly, so the explicit version input (which had to be kept in sync by hand) is no longer needed - one source of truth instead of two.
…ests CLI 2.109.1 now issues new sb_publishable_.../sb_secret_... format keys instead of the old fixed demo JWT anon key, so the hardcoded VITE_SUPABASE_PUBLISHABLE_KEY/TEST_SUPABASE_ANON_KEY literals no longer match what the local instance actually expects - every request from the app's Supabase client fails auth, which is why the e2e auth spec started timing out waiting for the sign-in button after the version bump. Read it from `supabase status -o env` after startup instead of hardcoding a literal, so this doesn't silently break again on the next CLI bump.
Visiting "/" chains through festival -> edition -> sets redirects before the header mounts; the default 5s toBeVisible timeout was tipping over under CI's parallel load. Wait for the final URL first instead of inflating the assertion timeout blindly.
This reverts commit 2855e79.
This reverts commit 02e15bf.
This reverts commit a28c158.
… in e2e tests" This reverts commit f1eb54d.
2.109.1 defaults local `supabase start` to sb_publishable_/sb_secret_ keys, and the anon-role auth path for those keys against this repo's local Postgrest/RLS setup doesn't work (every client request hangs/ fails, which is why the e2e auth spec timed out waiting on the header). 2.58.5 is the last version confirmed working against this stack; keep the setup-cli@v3 lockfile-based version detection and the dynamic `supabase status -o env` key export from the rest of this PR so this doesn't hand-drift out of sync again.
Unneeded now that the CLI is pinned back to 2.58.5 - that version works fine with the original hardcoded demo JWT anon key, so there's no need for the extra `supabase status -o env` parsing step this PR had added to work around 2.109.1's new key format.
chiptus
commented
Jul 10, 2026
2.58.5 confirmed the JWT-key regression was CLI-version-specific, not this repo's setup. 2.71.1 flipped the default local JWT signing algorithm from HS256 to ES256 with no opt-out (supabase/cli#4726), which breaks the hardcoded demo anon key's signature - so 2.70.0 is the newest version that stays on the working HS256 default while still picking up ~150 patch releases of fixes over 2.58.5.
Deliberately bumping to the exact version that switched local JWT signing from HS256 to ES256 by default, to confirm this is the version where e2e breaks (as expected from supabase/cli#4726). Diagnostic only.
… theory" This reverts commit 18fbf20.
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.
Bumps the pinned Supabase CLI version to 2.109.1 in
package.jsonand the two deploy workflows, since the previous^2.58.5pin combined with the action's auto-detect resolved unreliably (observed resolvingv2.20.3instead).Verification
db_migrateworkflow viaworkflow_dispatchon staging; confirmsupabase/setup-cliresolves2.109.1.deploy_edge_functionsworkflow viaworkflow_dispatch; confirm functions deploy successfully.Closes #33
Generated by Claude Code