deploy-from-stale-worktree-silent-rollbacklisted

Diagnose "I deployed a new Cloud Run / Docker image but a bunch of recently merged fixes regressed in production." Use when: (1) the deploy script does `gcloud builds submit ... "${SCRIPT_DIR}"` or `docker build <dir>` (build context = local filesystem, NOT a git ref), (2) the user has many git worktrees / multiple checkouts of the same repo, (3) the user reports "redeployed but the fix from PR #X isn't live" or "lots of fixes regressed after my deploy", (4) the deployed revision created at time T was authored by the user themselves (not CI). Root cause: deploy was run from a worktree whose HEAD predates the merged PRs; the build packaged stale local files, silently rolling back N commits worth of merged fixes. Provides the authoritative diagnostic (download Cloud Build source tarball + byte-diff against git history to identify the source commit) and the fix (rebuild from current main checkout, or instant traffic-switch rollback to the last known-good revision). v1.1 adds a pre-deploy preflight (5 lines from
wan-huiyan/agent-traffic-control · ★ 2 · DevOps & Infrastructure · score 79

Install: claude install-skill wan-huiyan/agent-traffic-control

# Deploy from a stale worktree silently rolls back merged fixes ## Problem The user merged a PR (or many PRs), redeployed the serving service, and reports the fix isn't live — sometimes "a lot of fixes regressed". The deployed image is brand new (recent timestamp, latest revision) and the deploy succeeded green. The diff between code and what's deployed is *not* a baking issue, *not* a browser cache issue — the **image itself contains old code**. This happens when the deploy script's build context is the local filesystem (`gcloud builds submit ... "${LOCAL_DIR}"`, `docker build <dir>`, `gcloud run deploy --source <dir>`, `kaniko --context dir://...`) and the user runs it from a stale checkout. With many git worktrees, it is easy to be sitting in `worktrees/foo/` 21 commits behind `main` and not notice — the deploy ships whatever is on disk. ## Trigger conditions All of these are typical: 1. The repo has a deploy script that uses one of: - `gcloud builds submit --tag=... "${SCRIPT_DIR}"` (no commit SHA tag) - `docker build -t ... <local-dir>` then push - `gcloud run deploy --source <local-dir>` 2. The user has multiple checkouts of the same repo (worktrees, sibling clones, IDE-managed copies). `git worktree list` shows ≥3 worktrees. 3. The user reports a regression after a self-initiated deploy (`serving.knative.dev/creator` on the new revision is the user's email, not a CI service account). 4. The "regressed" PRs were all merged BEFORE the deploy ti