ops: make deploy guards token + CLI version prerequisites - #81
Merged
Conversation
make deploy ran the deploy unconditionally: a missing SUPABASE_ACCESS_TOKEN (direnv doesn't fire non-interactively) failed with a misleading 403, and an outdated CLI that can't read deno.lock v5 died at bundling after auth succeeded. Both are now caught up front, as one guarded recipe line so the sourced token reaches the deploy in the same shell. Changes: - Makefile: add MIN_SUPABASE_CLI := 2.109.1; rewrite deploy as one logical recipe line — CLI-version guard (sort -V) then token guard (source .envrc only when the token is unset and .envrc exists) before the actual deploy - Makefile: an already-exported token is honoured as-is, a missing .envrc is not an error when the token is set, deno.lock is never touched - docs/operations.md §2: reconcile prose with the guards (#79) — Path A now guarded automatically, Path B still sources the token by hand Fixes #80
Fixed: - CLAUDE.md's "Edge function deploy" bullet described the pre-#80 manual .envrc-sourcing model and made no mention of the automatic token/CLI- version guards this PR added to `make deploy`, contradicting the shipped behavior for any session that reads only the summary. Skipped: - README.md L279/L303 (LOW, optional per docs-impact-findings.md) — still technically true, not filed as a standalone finding.
Owner
Author
⚡ Self-Fix Report (Aggressive)Status: COMPLETE Fixes Applied (1 total)
View all fixes
code-review-findings.md reported zero findings (APPROVE — both guards verified live in that review). Tests Added(none — Makefile/docs-only change, no runtime surface) Skipped (1)
Suggested Follow-up Issues(none) Validation
Self-fix by Archon · aggressive mode · fixes pushed to |
BluegReeno
marked this pull request as ready for review
July 27, 2026 13:28
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
1 participant
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
make deploynow guards its own two prerequisites — a missingSUPABASE_ACCESS_TOKENand an outdatedsupabaseCLI — before ever callingsupabase functions deploy, instead of failing deep into the deploy with a misleading 403 or a lockfile crash.deployrecipe as one shell invocation (\line-continuation), not.ONESHELL:, so the sourced token is visible to the deploy step without changingverify/test's per-line subshell semantics.docs/operations.md§2 (written in docs(operations): deploy prerequisites learned the hard way #79) is reframed, not duplicated: it now explains thatmake deployperforms both checks automatically, keeping the manual instructions only where they still apply (Path B, which bypassesmake deploy).Changes
MakefileMIN_SUPABASE_CLI := 2.109.1variable (the version that readsdeno.locklockfile v5).deployrecipe rewritten as a single logical recipe line, in order:set -e;(defense-in-depth against a malformed.envrc)supabase --versionagainstMIN_SUPABASE_CLIviasort -V; on failure, prints both versions and thebrew trust --formula supabase/tap/supabase && brew upgrade supabaseremedy to stderr,exit 1..envrconly whenSUPABASE_ACCESS_TOKENis unset and.envrcexists; if still unset, prints a named error pointing todocs/operations.md§2,exit 1. An already-exported token is honoured as-is and.envrcis never re-sourced; a missing.envrcis not itself an error.supabase functions deploy hal-mcp --no-verify-jwt && ./scripts/verify_deploy.sh.verifyandtesttargets are untouched — diff is scoped todeployand the new variable.deno.lockis never touched, deleted, or regenerated by this change.docs/operations.mdmake deployand needs manual sourcing); the CLI-version prose now reads as "the guard prints this remedy — run it, then retry" rather than a manual pre-flight step. Version numbers and the do-not-regenerate-the-lockfile warning are kept.Validation
make -n deploy— dry-run confirms the guarded recipe is one logical shell invocation, not silently split across subshells (the exact trap the issue warns about)..envrc→ exit 1, named error, never reaches the deploy call..envrcpresent →.envrcsourced in the same shell, token populated, deploy proceeds..envrcnot sourced.MIN_SUPABASE_CLItemporarily raised to99.0.0(viamake -e, no file edit) → exit 1, names both versions and thebrewremedy, no deploy attempt.make test(Level 3 offline suite) — unchanged pass:deno checkon both edge functions + 157 pytest passed, provingtest/verifyweren't affected.deno.lockconfirmed untouched.Full detail in the implementation/validation artifacts for this run.
Fixes #80