What Gets Captured
| Attribute | Description |
|---|---|
git_repo | Repository in owner/repo format |
git_ref | Commit SHA, tag, or branch name |
source_file | File path of the decorated function |
source_line | Line number |
source_function | Function name |
git_repo and git_ref are set at the trace level. source_file, source_line, and source_function are set per span automatically by @observe.
Configuration
TraceRoot resolves git context in this order: explicit init args →TRACEROOT_GIT_REPO / TRACEROOT_GIT_REF env vars → GitHub Actions env vars
(GITHUB_REPOSITORY / GITHUB_SHA) → local .git auto-detection.
Local .git auto-detection is a development convenience only. Production containers usually ship without a .git directory or the git binary, so auto-detection silently finds nothing and the AI agent cannot correlate traces to source. In production, always inject git context explicitly (see below).
Set them explicitly via environment variables:
Git context in production
Use build-time injection: inject the repo (static) and commit SHA (per-build) as environment variables at build time. The SDK reads them automatically — no code change required.Dockerfile
.github/workflows/deploy.yml
GITHUB_REPOSITORY and
GITHUB_SHA automatically — no Dockerfile change needed. On other CI/platform
providers, use the build-time injection above.
Apply this to every traced service, including background workers and cron/queue consumers — not just your API server. Each process resolves git context independently.
For setups that reuse one image across commits, set TRACEROOT_GIT_REPO /
TRACEROOT_GIT_REF in the Kubernetes pod spec or ECS task definition at deploy
time instead.