Files
Roberto Jiménez SánchezandClaude Opus 4.8 55f22a8689 Provisioning: trace repository build so secret decryption is visible (#131621)
* Provisioning: trace repository build so secret decryption is visible

The operator's per-job repository build decrypts the repo's token and
commit-signing-key via the secrets service. Those decrypt gRPC calls are
already instrumented, but they happened inside GetRepository with no
descriptive parent span, so in a job trace they hung anonymously under
provisioning.jobs.process_job and were easy to miss.

Wrap the build in a provisioning.jobs.build_repository span so the
decrypt calls stitch under a self-describing parent
(process_job -> build_repository -> DecryptSecureValues -> secrets-service).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* Provisioning: trace repository/connection build at the factory chokepoint

Move the build/decrypt span from the job driver to the repository and
connection factories — the single chokepoint every caller (job driver,
HTTP handlers, controllers, testers) funnels through to construct a
repository/connection, and where the token, commit-signing-key and
webhook secrets are decrypted via the secrets service. Tracing it here
gives those already-instrumented decrypt gRPC calls a descriptive parent
regardless of who triggered the build, instead of a span in just one caller.

The tracer is injected into ProvideFactory (threaded through the wiring and
the two Wire providers) rather than derived from the ambient span, matching
how the rest of the codebase obtains a tracer.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-27 11:20:02 +02:00
..