Skip to main content
TraceRoot automatically captures the git repository, commit, and the exact source file and line number for each instrumented function. This powers the Show Code feature in the trace viewer and enables the AI agent to jump directly from a failing trace to the relevant code.

​
What Gets Captured

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
In GitHub Actions, TraceRoot reads the standard 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.

​
Why It Matters

Source code correlation is what enables the AI agent to perform accurate root cause analysis — it can read the exact function that produced a failing span, not just the trace data. See Root Cause Analysis.