Version of orchestrion
v1.9.0 (with dd-trace-go v2.7.1)
Describe what happened:
When test binaries are built with Go's -trimpath flag (the recommended Go practice for reproducible builds), CI Visibility events emit @test.source.file values that are unusable for Datadog's CODEOWNERS detection.
With -trimpath, runtime.Func.FileLine returns the Go module path of a source file (e.g. github.com/myorg/myrepo/services/foo/foo_test.go) instead of an absolute filesystem path. dd-trace-go's GetRelativePathFromCITagsSourceRoot (internal/civisibility/utils/environmentTags.go) attempts filepath.Rel(workspacePath, path) on this input. Because the input isn't absolute, the result is a long ..-traversal path that still parses as "relative" (no error returned), so the function emits it as-is. The resulting path doesn't correspond to any file in the checked-out repo, so CODEOWNERS lookups in the Datadog Test Optimization UI never match.
Describe what you expected:
@test.source.file should be a repository-relative path that matches entries in the repo's CODEOWNERS file, regardless of whether the test binary was built with -trimpath. The integration should detect the trimmed-path case automatically (e.g. via runtime/debug.ReadBuildInfo() to obtain the binary's main module path, plus the git remote URL CI Visibility already collects) and produce a correct repo-relative path without requiring users to drop -trimpath or configure additional environment variables.
Steps to reproduce the issue:
- Build any Go test binary using orchestrion with
-trimpath:
go test -toolexec 'orchestrion toolexec' -trimpath ./...
- Submit any test in the repo. Inspect the resulting CI Visibility event in Datadog.
- Observe that
@test.source.file is github.com/<org>/<repo>/<path>/foo_test.go instead of <path>/foo_test.go.
- Confirm CODEOWNERS attribution is broken for that test in the DD Test Optimization UI.
Additional environment details (Version of Go, Operating System, etc.):
- Go: 1.26.1
- Build flags in use:
-trimpath, -vet=off, -tags=...
Version of orchestrion
v1.9.0 (with dd-trace-go v2.7.1)
Describe what happened:
When test binaries are built with Go's
-trimpathflag (the recommended Go practice for reproducible builds), CI Visibility events emit@test.source.filevalues that are unusable for Datadog's CODEOWNERS detection.With
-trimpath,runtime.Func.FileLinereturns the Go module path of a source file (e.g.github.com/myorg/myrepo/services/foo/foo_test.go) instead of an absolute filesystem path. dd-trace-go'sGetRelativePathFromCITagsSourceRoot(internal/civisibility/utils/environmentTags.go) attemptsfilepath.Rel(workspacePath, path)on this input. Because the input isn't absolute, the result is a long..-traversal path that still parses as "relative" (no error returned), so the function emits it as-is. The resulting path doesn't correspond to any file in the checked-out repo, so CODEOWNERS lookups in the Datadog Test Optimization UI never match.Describe what you expected:
@test.source.fileshould be a repository-relative path that matches entries in the repo'sCODEOWNERSfile, regardless of whether the test binary was built with-trimpath. The integration should detect the trimmed-path case automatically (e.g. viaruntime/debug.ReadBuildInfo()to obtain the binary's main module path, plus the git remote URL CI Visibility already collects) and produce a correct repo-relative path without requiring users to drop-trimpathor configure additional environment variables.Steps to reproduce the issue:
-trimpath:go test -toolexec 'orchestrion toolexec' -trimpath ./...
@test.source.fileisgithub.com/<org>/<repo>/<path>/foo_test.goinstead of<path>/foo_test.go.Additional environment details (Version of Go, Operating System, etc.):
-trimpath,-vet=off,-tags=...