Conversation
bouwkast
added
area:builds
BenchmarksBenchmark execution time: 2026-09-01 13:43:03 Comparing candidate commit d3f2fd0 in PR branch Found 1 performance improvements and 1 performance regressions! Performance is the same for 70 metrics, 0 unstable metrics, 68 known flaky benchmarks, 58 flaky benchmarks without significant changes.
|
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing This PR (9113) and master. ✅ No regressions detected |
Collaborator
Author
|
@codex review |
github-actions
Bot
added
the
area:builds
|
Codex Review: Didn't find any major issues. Chef's kiss. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Collaborator
Author
|
@codex review |
|
Codex Review: Didn't find any major issues. Breezy! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
bouwkast
marked this pull request as ready for review
August 25, 2026 17:21
andrewlock
reviewed
Aug 26, 2026
andrewlock
left a comment
andrewlock
left a comment
Member
There was a problem hiding this comment.
I may be missing something, but can't we use the existing "area" split instead of introducing a new concept? 🤔 Reasoning being, I figure we don't need to run civisibility tests on all PRs at all, same as we do for ASM?
Collaborator
Author
I think the Area filter is on the assembly / project level, but I was assuming that we would want to continue running CI Visibility tests on all PRs, if we don't want to do that then the Area logic is a better approach |
Collaborator
Author
@andrewlock Okay "I" made a large change to split them to be like that seeing as we want to drastically reduce PR CI time as well |
Collaborator
Author
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e2d3bb3389
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Comment on lines
+206
to
+207
| return _changedTeamValue.First(x => x.TeamName == CiVisibilityDotnet).IsChanged || | ||
| _changedTeamValue.First(x => x.TeamName == TracingDotnet).IsChanged; |
There was a problem hiding this comment.
For PRs whose only changes are in shared files owned solely by @DataDog/apm-dotnet, neither predicate is true, so every generated matrix omits the CIVisibility area. For example, Configuration/IntegrationId.cs is APM-owned but is directly exercised by the moved CI tests when configuring XUnit log submission. Before this split those tests were part of the unconditional Tracer entries; now behavioral regressions from such changes receive no CI Visibility test run. Track APM-owned changes here as well, or keep this area unconditional.
Useful? React with 👍 / 👎.
gh-worker-ownership-write-b05516
Bot
removed the request for review
from a team
September 1, 2026 12:53
Collaborator
Author
|
Closing in favor of #9169 |
andrewlock
added a commit
that referenced
this pull request
Sep 8, 2026
…icated jobs only when required (#9169) ## Summary of changes Splits out CiVisibility tests to only run when CI Visibility files have changed. ## Reason for change The CI Vis tests take a long time, and are getting longer with new major versions of xunit etc. Splitting them out as we do for ASM should reduce PR build times (and incidentally reduce chances of flake etc too). ## Implementation details This is an alternative approach to #9113, in which we keep using the `Area` approach. My thinking there was that we _might_ want to split this out later, + it also gives an easy mechanism for skipping _unit_ tests etc later as well if we want to, without introducing additional filter concepts. ## Test coverage This is the test. ## Other details Splitting the Windows integration tests doesn't really gain anything because hardly any ci vis tests run on windows, but I think it still makes sense for parity. I'm also thinking we _should_ split the arm64 integration tests now, as they're getting that much longer. I'll do a separate PR for that
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary of changes
This splits the CI Visibility tests to be run in in parallel to the rest of the other integration tests.
Reason for change
CI Visibility tests account for ~32% or so of the total time for the given run which was also getting very close to the overall job timeout.
Ideally this reduces the end to end CI time at the cost of needing additional agents running per CI run.
Implementation details
This adds an ability to partition integration tests, it likely should only be used here in this case and ideally removed if/when we reduce the time it takes for these tests.
Test coverage
Testing here to see if it works, you should see new splits in the integration tests on Linux for the tracer tests that will have a split for just the CI visibility tests.
Other details