Skip to content

docs(operations): deploy prerequisites learned the hard way - #79

Merged
BluegReeno merged 1 commit into
mainfrom
docs/deploy-prerequisites
Jul 26, 2026
Merged

docs(operations): deploy prerequisites learned the hard way#79
BluegReeno merged 1 commit into
mainfrom
docs/deploy-prerequisites

Conversation

@BluegReeno

Copy link
Copy Markdown
Owner

Documents three obstacles hit while deploying the #74 fix on 2026-07-25. Each one blocked the
deploy after the previous had been cleared, and none was in docs/operations.md §2 — which
anticipates the auth prerequisite well, but stops there.

  1. direnv does not fire in a non-interactive shell. A scripted make deploy gets no token
    and falls through to the personal account, failing with a 403 that reads like a permissions
    problem rather than a missing token. Path B already sources .envrc by hand; Path A needs the
    same whenever a tool drives the deploy.
  2. deno.lock is version 5 (since c19bec9, June) and CLI 2.72.7 cannot bundle it. The note
    explicitly says not to delete or regenerate the lockfile as a workaround — it pins the
    dependency versions that ship to production — and to upgrade the CLI instead. Homebrew now
    also refuses untrusted taps, hence the brew trust line.
  3. Neither make test nor CI runs the hal-mcp unit tests — see ci: hal-mcp unit tests never run — CI only type-checks #78. Adds the command that
    does, plus the reason SUPABASE_URL must be the real project URL (four OAuth-metadata tests
    assert the exact resource_metadata value).

Documentation only — no executable line changes.

Refs #78

🤖 Generated with Claude Code

Three things §2 did not say, each of which cost a failed deploy on 2026-07-25:

- direnv does not fire in a non-interactive shell, so a scripted `make deploy`
  silently uses the personal account and 403s.
- deno.lock is version 5; CLI < ~2.9x cannot bundle it. Says not to regenerate
  the lockfile, which pins what ships to production.
- neither `make test` nor CI runs the hal-mcp unit tests (#78) — documents the
  command that does, and why SUPABASE_URL must be the real project URL.

Refs #78

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@BluegReeno
BluegReeno merged commit 212e202 into main Jul 26, 2026
3 checks passed
BluegReeno added a commit that referenced this pull request Jul 27, 2026
* Fix: make deploy guards CLI version + token before deploying (#80)

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

* docs: reconcile CLAUDE.md deploy summary with #80 guards

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant