feat(container-runner): log version and git sha at actor start

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/rivet

• #5548 feat(container-runner): log version and git sha at actor sta … 👈
• #5549 feat(container-runner): setup instance memory and cpu usage …
• #5546 fix(rivetkit): keep actor event loop alive through shutdown …
• #5539 feat(container-runner): report actors as crashed on unexpect …
• #5536 feat(container-runner): log unexpected platform SIGTERM as a …
• #5530 fix(rivetkit-core): cancel driver alarm before sqlite teardo …
• #5531 feat(container-runner): keep instance warm instead of self-e …
• #5533 chore(container-runner): default stop grace to 10s
• #5528 fix(rivetkit): log and surface actor startup failures
• #5529 fix(rivetkit): treat empty actor input bytes as absent
• main

Get stack: forklift get 5548
Push local edits: forklift submit
Merge when ready: forklift merge 5548

_{change qolrvkqv}

[claude]

Review: feat(container-runner): log version and git sha at actor start

Nice, self-contained change with a well-thought-out fallback chain (OVERRIDE_GIT_SHA build-arg → local git rev-parse HEAD → "unknown", plus a runtime OVERRIDE_GIT_SHA env fallback). Two issues below look like they'd make the SHA silently not show up in the cases that matter most.

Issues

1. The real published container-runner binaries will likely never get a git SHA. container-runner/Dockerfile.release is where the OVERRIDE_GIT_SHA build-arg wiring lives, but that Dockerfile doesn't appear to be used by the actual release pipeline. .github/workflows/publish.yaml builds the binary that's uploaded to releases.rivet.dev (the one users curl per deploy/container-runner.mdx) via docker/build/linux-x64-musl.Dockerfile / linux-arm64-musl.Dockerfile, passing only BUILD_TARGET, BUILD_MODE, and BUILD_FRONTEND as build args, no OVERRIDE_GIT_SHA. Since the repo's root .dockerignore excludes .git/ from every Docker build context, build.rs's local git rev-parse HEAD fallback also can't find a repo in that build. So CONTAINER_RUNNER_GIT_SHA compiles to "unknown" for the shipped binary, and crate::git_sha() returns None at runtime unless an operator separately sets OVERRIDE_GIT_SHA in the container's env (which isn't documented anywhere). Net effect: the feature works for a local cargo build and for a Dockerfile that isn't actually part of CI, but not for what users actually download and run.

   Suggested fix: pass --build-arg OVERRIDE_GIT_SHA=${{ needs.context.outputs.sha }} (that value already exists in the workflow) in the depot build step for the container-runner (and ideally the other) matrix targets in publish.yaml.

2. build.rs's local git fallback will go stale between commits during dev iteration. It emits cargo:rerun-if-env-changed=OVERRIDE_GIT_SHA but no cargo:rerun-if-changed=... pointing at the git ref/HEAD files. Once any rerun-if-* instruction is emitted, Cargo disables its default "rerun if any file in the package changed" heuristic and only reruns the build script on the declared triggers. Since there's no trigger tied to the git HEAD, a local dev loop of cargo build → commit → cargo build again (without touching OVERRIDE_GIT_SHA) will keep embedding the SHA from the first build until something else forces a rebuild of build.rs's output (e.g. cargo clean, editing build.rs, bumping Cargo.toml). That undermines exactly the "colocated dev builds" path called out in the file's own doc comment. Consider adding something like println!("cargo:rerun-if-changed=../.git/HEAD"); (adjusted for the actual workspace-root .git path) so new commits are picked up.

Minor / nit

• engine/packages/util/build.rs already solves this same "embed git SHA, .git excluded from Docker context" problem via vergen + vergen_gitcl with the same OVERRIDE_GIT_SHA env-var override convention. Not a blocker, but worth considering reusing that pattern here instead of a hand-rolled std::process::Command shell-out, so the two runner binaries in the monorepo don't carry two different implementations of the same idea.

Other notes

• The per-actor-start log placement (tagged with actor_id) and the match on Option<String> instead of an unwrap_or (to avoid logging a redundant git_sha="unknown" field) both look intentional and reasonable.
• Logging via tracing::info! with structured fields (actor_id, version, git_sha) matches the repo's logging conventions.

No test coverage was added, which is understandable given this is startup-log plumbing, but a smoke/integration check that a CI-built binary actually embeds a real (non-"unknown") SHA would have caught issue #1.