deploy-from-stale-worktree-silent-rollback

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 timestamp — they exist on origin/main but not necessarily in the local cwd.
5. There is no commit SHA visible on the deployed image (only :latest or no tag at all). This is a strong tell that the build context was local FS, not a git ref.

Pre-deploy preflight (catch the trap BEFORE it fires)

Run this preflight from the deploy script's directory before you invoke the build. It costs ~1s and catches every variant of this trap without needing to inspect Cloud Build tarballs after the fact.