`secrets set` ignores `--workdir` and reads config.toml from the working directory

Chiusa
  • Qualcosa non va?
#7,354 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
Mezza giornata
Idoneità per principianti
58/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
cli

Direzione di ricerca

Start in apps/cli/src/commands/secrets/set/set.handler.ts, where loadCliConfig and loadCliProjectEnvironment are called with runtimeInfo.cwd. Compare with apps/cli/src/commands/config/config.load.ts, which uses cliSettings.workdir, and with runtimeInfo.cwd in apps/cli/src/shared/runtime/runtime-info.layer.ts. Done when the repro run with --workdir ../clean from leaky/ fails with SecretsNoArgumentsError and sends no request.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

🐛 Bug supabase/cli

Describe the bug

supabase secrets set resolves supabase/config.toml by searching up from process.cwd(), so --workdir has no effect on which config it reads. The command merges that file's [edge_runtime.secrets] into its request body, so running it from a directory whose config declares local-only secrets pushes those values to the target project — even when --workdir points at a different, secret-free project directory.

config push, config diff and config pull do honour --workdir, which makes the behaviour of secrets set surprising.

To reproduce

mkdir -p leaky/supabase clean/supabase

cat > leaky/supabase/config.toml <<'EOF'
project_id = "leaky"

[edge_runtime.secrets]
LOCAL_ONLY = "http://127.0.0.1:54324"
EOF

printf 'project_id = "clean"\n' > clean/supabase/config.toml

cd leaky
supabase secrets set --project-ref <ref> --workdir ../clean --output-format json

No secrets are passed on the command line, so anything the command sends can only have come from a config file.

Expected behavior

--workdir ../clean is used, clean/supabase/config.toml declares no [edge_runtime.secrets], and the command fails with SecretsNoArgumentsError without sending a request.

Actual behavior

It reads leaky/supabase/config.toml and posts LOCAL_ONLY to the project:

{"_tag":"Error","error":{"code":"SecretsSetNetworkError","message":"failed to set secrets: TransportError"}}

(a request was built and attempted — here with outbound traffic blocked, to keep the test off a real project)

Running the identical command from clean/ instead gives:

{"_tag":"Error","error":{"code":"SecretsNoArgumentsError","message":"No arguments found. Use --env-file to read from a .env file."}}

So only the working directory decides which config is read.

Version

Reproduced on 2.118.0 and present in 2.122.0.

Where it comes from

apps/cli/src/commands/secrets/set/set.handler.ts calls loadCliConfig(runtimeInfo.cwd, …) and loadCliProjectEnvironment({ cwd: runtimeInfo.cwd, … }). runtimeInfo.cwd is process.cwd() in apps/cli/src/shared/runtime/runtime-info.layer.ts and never reflects --workdir. By contrast apps/cli/src/commands/config/config.load.ts loads from cliSettings.workdir and respects shouldSearchAncestors.

Why it matters

A natural way to keep local-only Edge Function secrets out of a hosted project is to keep them in one config.toml and run secrets set with --workdir pointed at another directory whose config has no secrets table. That doesn't work, and the merge is silent: nothing in the output names the secrets the config contributed, so the extra values are only visible afterwards in secrets list.

A fix could either honour --workdir here as the config commands do, or — separately useful — list the config-sourced names the command is about to send.

Lingua principale
TypeScript
Stelle
2.4k
Fork
540
Merge medio
17h 3m
PR unite (30g)
390

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di supabase/cli

Tutte le issue di supabase/cli

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.