Intercept and collect spans in test runner #14065
Merged
+2,031
−818
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related to #13468
Apologies for the large change set, I implemented some ordering to try and make the yaml output deterministic going forward. Future updates should be easier to understand without any random positional drift.
This concludes most of the underlying plumbing needed to gather all the required metadata (at least for this phase of the project). After this is merged, I will continue going through module to module to populate the
metadata.yaml
data, and enabling and validating the telemetry collection results in batches. I will update the issue with a checklist so we can ensure we hit them all. Once all modules have been validated and rolled out, I can cleanup the span specific feature flag.Things I changed in this PR:
span-
files into the.telemetry
directoriesspan kind
This change will result in new span files being generated in the
.telemetry
directory, example:And after we parse, deduplicate, and filter out test related spans and attributes, we see an end result in the instrumentation-yaml file: