ci(deploy): stamp deploys with git SHA so /version reports the commit

[lukaso-bot]

What

Pass --tag <short-sha> and --message commit-<full-sha> to both wrangler deploy steps in release.yml (web and web-og).

Why

The deploy steps ran bare, so Cloudflare's version_metadata.tag was always empty and GET /version returned only an opaque version UUID (e.g. b3f09445-…). Correlating a live deploy back to its git commit — the first question during any incident — meant hand-matching deploy timestamps. The maintaining loop has worked around this every cycle since the /version endpoint shipped (cycle 15, PR #40).

After this, /version returns the 8-char short SHA in tag, and wrangler deployments list shows commit-<full-sha> in the message.

Details

• Tag = short SHA, not full. wrangler caps a version tag at ~25 chars; a full 40-char SHA would make the deploy step fail. The 8-char short SHA is unique enough to grep and safely within the limit. Full SHA goes in --message (the more generous field).
• No Worker code change. The /version route already surfaces CF_VERSION_METADATA.tag (packages/web/src/index.ts); it just had nothing to report. Verified --tag/--message exist on wrangler deploy against the Wrangler commands docs (they "match the behavior of wrangler versions upload --tag/--message").
• No injection surface. github.sha is a hex-only commit hash; the short-SHA run: step reads it via an env: var per the safe Actions pattern, and both deploy values are space-free single tokens so the wrangler-action command input needs no quoting.

Test plan

CI-only / deploy-config change (TDD config exception). Local pre-push gate (scripts/validate.sh) green: build, typecheck, test, lint, actionlint, shellcheck, gitleaks, publint. The real verification is post-merge: after this deploys, curl https://released.blabberate.com/version should return a populated "tag" matching the merge commit's short SHA.

🤖 Generated with Claude Code

[lukaso-bot]

In-house adversarial review (Copilot quota-blocked here → no automated review will land)

Per review-policy, Copilot is perpetually quota-blocked on this repo, so I ran a skeptical pass. This is a deploy-toolchain change to release.yml that only executes on push to main — never on a PR — so the 8 green PR checks do not exercise it. That makes the correctness of the wrangler invocation the whole ballgame, and a wrong flag would fail every prod deploy. So I verified the external-tool claims against the authoritative docs (the #110 class).

Crux claim — does wrangler deploy accept --tag / --message? ✅ Verified against the Cloudflare Workers commands docs. wrangler deploy lists both:

• --tag — "A tag for this Worker version. Matches the behavior of wrangler versions upload --tag."
• --message — "A descriptive message for this Worker version and deployment. Matches the behavior of wrangler versions upload --message."

The PR's stated rationale matches the docs verbatim. (Belt-and-suspenders: I also grepped the installed wrangler@4.90.1 bundle — inconclusive because it's minified, so the docs are the authority here, and they confirm it.)

Deploy can't fail on tag length. The only way a --tag value breaks a deploy is exceeding the API's version-tag cap. The chosen value is the 8-char short SHA, safely under any plausible cap; the full 40-char SHA goes in --message (the generous field). Even if the exact cap differs from the "~25 chars" in the PR body, the chosen short SHA is robust either way — no deploy-failure surface.

Injection / quoting. github.sha is a hex-only commit hash, so neither interpolation is an injection vector. Both deploy values (<short-sha>, commit-<full-sha>) are single space-free tokens, so the wrangler-action command input needs no shell quoting. The short SHA is computed in a separate step reading github.sha via an env: var (the recommended safe-Actions pattern). ✅

Mechanism. No Worker code change is needed — /version already surfaces CF_VERSION_METADATA.tag (packages/web/src/index.ts); it just had nothing to report. With --tag set, version_metadata.tag populates. ✅ Deploy order (web → web-og) is unchanged. ✅

One non-blocking observation (not a merge blocker): --message commit-${{ github.sha }} interpolates github.sha directly into the YAML command string, whereas the short SHA is routed through an env: var first. Both are safe here because the value is hex-only; routing the message through the same env: pattern would make the safe-interpolation convention uniform across both args. Optional polish, not required.

Verdict: correctness verified against docs; no blocking issues; mergeable. Posted as a comment (GitHub won't let the PR author self-approve). Real proof is post-merge: curl https://released.blabberate.com/version should return a populated "tag" = the merge commit's short SHA.