Activity

Why

PR #172 added a git rev-parse fallback in vite.config.ts, expecting it to work inside Coolify's Docker frontend-build stage where .git is present via COPY . .. It didn't — the staging deploy after merge still tagged the release as dev.

Confirmed by docker exec into the new staging container: bundle still contains e.SENTRY_RELEASE={id:\"dev\"}. Sentry's Releases API shows the only dev entry was created at 06:25 — no per-commit releases.

Root cause (most likely)

Coolify clones the repo as one uid (the helper container's user) and the build runs as another (root in the Dockerfile), so modern git refuses to read .git without an explicit safe.directory entry. The try/catch in resolveSentryRelease() then swallowed the error.

Fix

Move the resolution into the Dockerfile, where:

1. We can add git config --global --add safe.directory /app to bypass the ownership check.
2. We can echo the resolved value so it lands in deploy logs — visible debugging for next time something goes sideways.
3. We pass SOURCE_COMMIT into npm run build:ssr as an env var — vite.config.ts already prefers it over the in-process git call.

Also widened the vite.config.ts catch to console.warn the actual error message on local builds. If git misbehaves locally, we'll see what it said instead of silently shipping dev.

Local verification

npm run build from main:

tidylinker@49a17f07d647

Matches git rev-parse --short=12 HEAD exactly.

Test plan

• Local smoke build → real SHA, no dev
• After merge → staging deploys → exec into container, confirm tidylinker@<sha> in bundle (not dev)
• Deploy log shows Build SOURCE_COMMIT=<sha> line
• Sentry → Releases shows a new entry under that name with uploaded artifacts
• Trigger one of the open frontend errors (or wait), confirm the stack has real file paths
• Then prod deploy