coordinator: stamp build version/commit into /health via ldflags

[ethenotethan]

Problem

The live coordinator at api.darkbloom.dev/health reported build=dev / commit=unknown for 4 consecutive days (2026-06-26 → 06-29), so the running binary could not be traced to a git tag/SHA — a release-traceability and incident-triage gap. (DAR-371, closes #485)

Cloud Build (deploy/gcp/cloudbuild.yaml) already tags images with $SHORT_SHA, but that SHA was never threaded into the binary's version string, so the api.Build* vars kept their dev/unknown defaults.

Fix

Inject the build metadata via -ldflags -X at build time:

• coordinator/Dockerfile — new GIT_COMMIT / GIT_VERSION build args (default unknown/dev so plain docker build still works) stamped into go build; BuildDate set to image build time. Stamps both coordinator/api.{BuildVersion,BuildCommit,BuildDate} and coordinator/telemetry.CoordinatorVersion.
• deploy/gcp/cloudbuild.yaml — pass --build-arg GIT_COMMIT=$SHORT_SHA and --build-arg GIT_VERSION=$SHORT_SHA to the docker build step.
• Makefile — stamp the same ldflags from git for local/manual coordinator-build and coordinator-build-linux.

The same coordinator/Dockerfile is the image EigenCloud prod uses, so both the GCP dev VM and EigenCloud prod /health become traceable.

Verification

Compiled the coordinator with the ldflags (go 1.25) — build succeeds; go tool nm confirms all four symbols are stamped and the short SHA is embedded in the binary:

api.BuildVersion / api.BuildCommit / api.BuildDate / telemetry.CoordinatorVersion  → present

After this lands and redeploys, GET /health returns the real version / build_commit / build_date instead of dev / unknown.

Triage note from the issue: it's still worth confirming whether api.darkbloom.dev is the dev or prod surface, and whether the EigenCloud prod coordinator likewise reported dev/unknown. This change fixes traceability for both since they share the Dockerfile.

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
d-inference	Ready	Preview	Jun 29, 2026 11:14pm
d-inference-console-ui-dev	Ready	Preview	Jun 29, 2026 11:14pm
d-inference-landing	Ready	Preview	Jun 29, 2026 11:14pm

[github-actions]

No threat-model-covered files were changed; these are build/deploy infrastructure changes that fall outside current threat model coverage.

---

Trust boundaries touched

None of the three changed files map to any existing TB-xxx boundary.

---

Threat assessment

No existing T-xxx threats are affected.

---

New attack surface to evaluate

The changed files warrant a brief human review for two reasons that sit just outside the current threat model's explicit scope:

coordinator/Dockerfile

• If base image, added packages, or exposed ports changed, this could affect the coordinator's runtime attack surface (relevant to TB-001, TB-002, TB-006 indirectly). Specifically: any new COPY/ADD of secrets or credentials at image build time, any new EXPOSE directives, or a base image downgrade could introduce risk the threat model would want to track.
• Recommendation: verify the base image is pinned to a digest (not a mutable tag) and that no secrets are baked into image layers.

deploy/gcp/cloudbuild.yaml

• Cloud Build pipelines can introduce supply-chain-adjacent risk (pushing to registries, handling service-account tokens, running arbitrary steps). This is noted as out of scope in the current threat model ("GitHub Actions / R2 release supply chain"), and GCP Cloud Build falls in the same category. No action needed unless the coordinator's production deployment pipeline is considered in-scope — if so, this file should be added to TB-006's affected_files.

Makefile

• Local developer tooling only. No new trust-boundary surface.

---

Suggested threat model update

If GCP Cloud Build is now part of the production deployment path for the coordinator, consider adding deploy/gcp/cloudbuild.yaml and coordinator/Dockerfile to the affected_files list of T-024 (admin/release key compromise enabling binary hash manipulation) and T-013 (operator modifies coordinator binary), since these files control what binary is actually deployed to the TEE.

---

🔐 Threat model: docs/threat-model.yaml · Updates on each push to this PR

[Gajesh2007]

@codex - give this a review

[ethenotethan]

Automated Code Review — Layr-Labs/d-inference#

Verdict: COMMENT

Security — ✅ No issues found

Performance — ✅ No issues found

Type_diligence — ✅ No issues found

Additive_complexity — ✅ No issues found

✅ All four passes clean. No issues found.

🤖 Automated review by Centaur · DAR-186

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 68e26437f2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Stamp EigenCloud builds instead of defaults

The documented prod deploy path is ecloud compute app deploy d-inference against coordinator/Dockerfile (see docs/operations/coordinator-deploy.md:60-63), and it does not go through deploy/gcp/cloudbuild.yaml, the only place this PR supplies --build-arg. In that EigenCloud context these ARG defaults are what get used, so prod /health still reports version=dev and build_commit=unknown; either derive the values inside the Docker build or add build-arg wiring to the EigenCloud deploy path.

Useful? React with 👍 / 👎.