Closed #6 Bug

filed by gabriel human · 37 days ago

deploy.sh hardcodes Nonproduction ECR registry — prod deploy authenticates to the wrong account

0 Anchors

— Blast radius

— Churn 30d

0 Proposals

Summary

Prod deploy from a clean checkout is still broken: deploy.sh:36 hardcodes the Nonproduction ECR registry, and :202-204 logs into it, while :47 pulls whatever image push.sh passes in — so a "prod" deploy authenticates to the Nonproduction registry while trying to pull an image that was pushed to (and only exists in) Production's registry.

Why staging#159 didn't catch this

staging#159 closed with "deploy.sh needed no changes — it already takes ECR_IMAGE as a parameter." That's true of ECR_IMAGE, but not of ECR_REGISTRY — and ECR_REGISTRY is what docker login actually uses. The gap survived because nothing had cause to open deploy.sh itself during that work:

staging#150 fixed push.sh's per-environment auth (separate script).
staging#159 concluded deploy.sh was already parameterized (true only for the image, not the registry).
07-secrets-and-config.md notes deploy.sh/secrets.sh are deliberately decoupled — reasonable in general, but it meant no one re-checked deploy.sh's own registry logic when push.sh went per-environment.

Fix

aaronrene has this branched off dev @ 8a1389ae — 2 files, 26 tests. Was queued behind staging#193 (the accepted_at push-blocker), which is now fixed and deployed — this is unblocked.

staging#159 — closed without catching this; not reopened (the closure was correct for what it covered), but this ticket documents the gap it missed.

Source

Reported by aaronrene, 2026-09-10 (relayed via message to gabriel, processed 2026-09-11).

Mirrored from staging#194.

◎ Activity1

●

gabriel opened this issue 37 days ago

○

gabriel 37 days ago

Fixed and deployed to staging and production.

Root cause: deploy.sh:36 hardcoded the Nonproduction ECR registry independently of ECR_IMAGE, and docker login used that hardcoded registry — so a prod deploy authenticated against the wrong account while trying to pull an image that only existed in production's registry.

Fix: ECR_IMAGE is now the single source of truth; ECR_REGISTRY is derived from it (ECR_REGISTRY="${ECR_IMAGE%%/*}") instead of being independently hardcoded — login and pull now always target the same registry.

Tests: new TestEcrRegistryDerivedFromImage in tests/test_deployment.py (5 tests), executing the real bash variable-derivation lines in a subprocess.

Verified via a real bash deploy/push.sh staging run and confirmed again with this session's subsequent staging+prod deploys, all succeeding against the correct registry.

✓

closed this issue 37 days ago

Assignee

○ unassigned

Release

no commits linked to this issue

create

muse hub issue create \
  --title "..." \
  --body "..." \
  --label bug \
  --anchor path/to/file.py::Symbol \
  --commit-anchor <sha> \
  --repo gabriel/musehub

read

muse hub issue get 6 --json
muse hub issue list --state open --json

update

muse hub issue edit 6 \
  --anchor path/to/file.py::Symbol \
  --repo gabriel/musehub

comment

muse hub issue comment 6 \
  --body "Fixed in <sha>" \
  --repo gabriel/musehub

reopen

muse hub issue reopen 6 \
  --repo gabriel/musehub

create

create_issue({
  repo_id: "sha256:85a773e186fe54d0340d6a7bc51ebcb15fe763ffb74b24b5915b3c695aed3340",
  title: "...",
  body: "...",
  labels: ["bug"],
  symbol_anchors: [
    "path/to/file.py::Symbol"
  ],
  commit_anchors: ["<sha>"]
})

read

get_issue({
  repo_id: "sha256:85a773e186fe54d0340d6a7bc51ebcb15fe763ffb74b24b5915b3c695aed3340",
  issue_number: 6
})

list_issues({
  repo_id: "sha256:85a773e186fe54d0340d6a7bc51ebcb15fe763ffb74b24b5915b3c695aed3340",
  state: "open"
})

update

edit_issue({
  repo_id: "sha256:85a773e186fe54d0340d6a7bc51ebcb15fe763ffb74b24b5915b3c695aed3340",
  issue_number: 6,
  symbol_anchors: ["path/to/file.py::Symbol"]
})

comment

create_issue_comment({
  repo_id: "sha256:85a773e186fe54d0340d6a7bc51ebcb15fe763ffb74b24b5915b3c695aed3340",
  issue_number: 6,
  body: "..."
})

reopen

reopen_issue({
  repo_id: "sha256:85a773e186fe54d0340d6a7bc51ebcb15fe763ffb74b24b5915b3c695aed3340",
  issue_number: 6
})

create

curl -X POST \
  http://localhost:10003/api/repos/sha256:85a773e186fe54d0340d6a7bc51ebcb15fe763ffb74b24b5915b3c695aed3340/issues \
  -H "Content-Type: application/json" \
  -H "Authorization: MSign handle=\"...\" ts=... sig=\"...\"" \
  -d '{
    "title": "...",
    "body": "...",
    "labels": ["bug"],
    "symbol_anchors": ["path/to/file.py::Symbol"]
  }'

read

# get one issue
curl http://localhost:10003/api/repos/sha256:85a773e186fe54d0340d6a7bc51ebcb15fe763ffb74b24b5915b3c695aed3340/issues/6

# list open issues
curl "http://localhost:10003/api/repos/sha256:85a773e186fe54d0340d6a7bc51ebcb15fe763ffb74b24b5915b3c695aed3340/issues?state=open"

update

curl -X PATCH \
  http://localhost:10003/api/repos/sha256:85a773e186fe54d0340d6a7bc51ebcb15fe763ffb74b24b5915b3c695aed3340/issues/6 \
  -H "Content-Type: application/json" \
  -H "Authorization: MSign handle=\"...\" ts=... sig=\"...\"" \
  -d '{"title": "...", "body": "..."}'

comment

curl -X POST \
  http://localhost:10003/api/repos/sha256:85a773e186fe54d0340d6a7bc51ebcb15fe763ffb74b24b5915b3c695aed3340/issues/6/comments \
  -H "Content-Type: application/json" \
  -H "Authorization: MSign handle=\"...\" ts=... sig=\"...\"" \
  -d '{"body": "Fixed in <sha>"}'

reopen

curl -X POST \
  http://localhost:10003/api/repos/sha256:85a773e186fe54d0340d6a7bc51ebcb15fe763ffb74b24b5915b3c695aed3340/issues/6/reopen \
  -H "Authorization: MSign handle=\"...\" ts=... sig=\"...\""

deploy.sh hardcodes Nonproduction ECR registry — prod deploy authenticates to the wrong account

Summary

Why staging#159 didn't catch this

Fix

Related

Source