PR #174 opened: fix: loud diagnostics for git SHA resolution in Docker build
Why
PR #173's Dockerfile-based git resolution still shipped `release=dev` to staging. Either git silently failed inside Coolify's BuildKit (whose debug logs the MCP `mcp__coolify__deployment` doesn't expose — only the wrapper-level logs) or my RUN logic has a hole I can't see from here.
I've burned three PRs guessing. Time to stop guessing and let the build tell us what happened.
Changes
`Dockerfile` only — two diagnostic levers:
-
Fail loud instead of silent. Removed the `|| true` after `git rev-parse`. If git fails, the build now fails outright with a clear error in the deploy log. Better one broken deploy than another `dev` deploy slipping through unnoticed.
-
Make the resolved value inspectable from the running container. The frontend-build RUN now writes the resolved SHA to `/tmp/build-sha` and the production stage copies that into `/var/www/html/.build-sha`. After deploy I can `docker exec ... cat /var/www/html/.build-sha` and see the actual value that reached `npm run build:ssr` — independent of build-log access.
Also added `echo` of pwd, `ls .git`, and `git --version` at the top of the RUN so if the next deploy DOES fail, the failure message will tell us exactly which assumption was wrong.
Test plan
- Local: build still passes
- After merge: staging deploys. Two outcomes possible:
- Build fails with a clear git error → we'll know the root cause from the deploy log diagnostic lines
- Build succeeds → `docker exec ... cat /var/www/html/.build-sha` shows the real SHA AND the bundle should now contain `tidylinker@
`
- Sentry releases page shows new entry with uploaded artifacts
- Prod deploy