Open
Conversation
andrewlock
added
area:builds
![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: 6598bb787a
ℹ️ 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".
andrewlock
commented
Mar 4, 2026
| COPY --chown=$APP_UID --from=builder /empty/ /var/log/datadog/dotnet/ | ||
|
|
||
| # Ensure /app is writable by the non-root user (for completed.txt marker) | ||
| COPY --chown=$APP_UID --from=builder /empty/ /app/ |
Member
Author
There was a problem hiding this comment.
This is a funny one, I don't think it can ever have been working, so I think this is fine
andrewlock
commented
Mar 4, 2026
| cd /install; \ | ||
| Expand-Archive 'c:\install\windows-tracer-home.zip' -DestinationPath 'c:\monitoring-home\'; \ | ||
| c:\install\installer\Datadog.FleetInstaller.exe install-version --home-path c:\monitoring-home; \ | ||
| c:\install\Datadog.FleetInstaller.exe install-version --home-path c:\monitoring-home; \ |
Member
Author
There was a problem hiding this comment.
dropping the installer intermediate directory just makes the artifact download step a bit simpler
andrewlock
commented
Mar 4, 2026
|
|
||
| return scenarios.SelectMany(x => x); | ||
|
|
||
| // ───────────────────────────────────────────────────────── |
Member
Author
There was a problem hiding this comment.
This is essentially the same matrix of tests we ran previously
andrewlock
commented
Mar 4, 2026
| throw new Exception("Failed to download telemetry forwarder"); | ||
| } | ||
|
|
||
| static string GetDotnetSdkVersion(AbsolutePath rootDirectory) |
Member
Author
There was a problem hiding this comment.
Could be handy elsewhere too tbh, though I haven't used it anywhere yet
andrewlock
commented
Mar 4, 2026
| ? "Successfully submitted metric" | ||
| : "Failed to submit metric"; | ||
| log.Warning("{Result} {MetricName} to {Uri}. Response was: Code: {ResponseStatusCode}. Response: {ResponseContent}. Payload sent was: \"{Payload}\"", result, metricName, uri, response.StatusCode, responseContent, payload); | ||
| var level = response.IsSuccessStatusCode ? LogEventLevel.Debug : LogEventLevel.Warning; |
Member
Author
There was a problem hiding this comment.
This was incorrectly logging as a warning even for success, which causes it to show up in the azdo logs
BenchmarksBenchmark execution time: 2026-03-06 15:00:15 Comparing candidate commit a8f3d3b in PR branch Found 11 performance improvements and 6 performance regressions! Performance is the same for 157 metrics, 18 unstable metrics. scenario:Benchmarks.Trace.AgentWriterBenchmark.WriteAndFlushEnrichedTraces net6.0
scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.AllCycleSimpleBody net6.0
scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorMoreComplexBody net6.0
scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorSimpleBody netcoreapp3.1
scenario:Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark.WriteAndFlushEnrichedTraces net6.0
scenario:Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark.WriteAndFlushEnrichedTraces netcoreapp3.1
scenario:Benchmarks.Trace.CharSliceBenchmark.OptimizedCharSlice netcoreapp3.1
scenario:Benchmarks.Trace.ElasticsearchBenchmark.CallElasticsearchAsync net472
scenario:Benchmarks.Trace.ILoggerBenchmark.EnrichedLog net6.0
scenario:Benchmarks.Trace.Iast.StringAspectsBenchmark.StringConcatBenchmark net6.0
scenario:Benchmarks.Trace.Log4netBenchmark.EnrichedLog netcoreapp3.1
scenario:Benchmarks.Trace.SerilogBenchmark.EnrichedLog net6.0
scenario:Benchmarks.Trace.SingleSpanAspNetCoreBenchmark.SingleSpanAspNetCore netcoreapp3.1
scenario:Benchmarks.Trace.SpanBenchmark.StartFinishSpan netcoreapp3.1
scenario:Benchmarks.Trace.TraceAnnotationsBenchmark.RunOnMethodBegin net6.0
|
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing This PR (8271) and master. ✅ No regressions detected - check the details below Full Metrics ComparisonFakeDbCommand
HttpMessageHandler
Comparison explanationExecution-time benchmarks measure the whole time it takes to execute a program, and are intended to measure the one-off costs. Cases where the execution time results for the PR are worse than latest master results are highlighted in **red**. The following thresholds were used for comparing the execution times:
Note that these results are based on a single point-in-time result for each branch. For full results, see the dashboard. Graphs show the p99 interval based on the mean and StdDev of the test run, as well as the mean value of the run (shown as a diamond below the graph). Duration chartsFakeDbCommand (.NET Framework 4.8)gantt
title Execution time (ms) FakeDbCommand (.NET Framework 4.8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8271) - mean (77ms) : 75, 80
master - mean (75ms) : 73, 77
section Bailout
This PR (8271) - mean (81ms) : 79, 84
master - mean (79ms) : 78, 81
section CallTarget+Inlining+NGEN
This PR (8271) - mean (1,102ms) : 1056, 1148
master - mean (1,089ms) : 1047, 1130
FakeDbCommand (.NET Core 3.1)gantt
title Execution time (ms) FakeDbCommand (.NET Core 3.1)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8271) - mean (119ms) : 115, 123
master - mean (117ms) : 113, 120
section Bailout
This PR (8271) - mean (120ms) : 117, 123
master - mean (118ms) : 115, 121
section CallTarget+Inlining+NGEN
This PR (8271) - mean (790ms) : 721, 858
master - mean (766ms) : 708, 823
FakeDbCommand (.NET 6)gantt
title Execution time (ms) FakeDbCommand (.NET 6)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8271) - mean (107ms) : 104, 110
master - mean (104ms) : 101, 107
section Bailout
This PR (8271) - mean (107ms) : 105, 110
master - mean (105ms) : 103, 107
section CallTarget+Inlining+NGEN
This PR (8271) - mean (770ms) : 688, 852
master - mean (768ms) : 707, 828
FakeDbCommand (.NET 8)gantt
title Execution time (ms) FakeDbCommand (.NET 8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8271) - mean (105ms) : 102, 108
master - mean (103ms) : 100, 105
section Bailout
This PR (8271) - mean (107ms) : 105, 110
master - mean (103ms) : 101, 105
section CallTarget+Inlining+NGEN
This PR (8271) - mean (696ms) : 667, 725
master - mean (681ms) : 651, 712
HttpMessageHandler (.NET Framework 4.8)gantt
title Execution time (ms) HttpMessageHandler (.NET Framework 4.8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8271) - mean (197ms) : 192, 203
master - mean (195ms) : 191, 199
section Bailout
This PR (8271) - mean (200ms) : 196, 204
master - mean (199ms) : 196, 202
section CallTarget+Inlining+NGEN
This PR (8271) - mean (1,163ms) : 1101, 1226
master - mean (1,155ms) : 1095, 1215
HttpMessageHandler (.NET Core 3.1)gantt
title Execution time (ms) HttpMessageHandler (.NET Core 3.1)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8271) - mean (283ms) : 274, 291
master - mean (279ms) : 272, 286
section Bailout
This PR (8271) - mean (283ms) : 276, 289
master - mean (279ms) : 275, 284
section CallTarget+Inlining+NGEN
This PR (8271) - mean (954ms) : 899, 1009
master - mean (950ms) : 913, 986
HttpMessageHandler (.NET 6)gantt
title Execution time (ms) HttpMessageHandler (.NET 6)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8271) - mean (274ms) : 268, 280
master - mean (274ms) : 268, 279
section Bailout
This PR (8271) - mean (274ms) : 270, 277
master - mean (272ms) : 269, 276
section CallTarget+Inlining+NGEN
This PR (8271) - mean (939ms) : 908, 971
master - mean (934ms) : 903, 965
HttpMessageHandler (.NET 8)gantt
title Execution time (ms) HttpMessageHandler (.NET 8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8271) - mean (272ms) : 267, 278
master - mean (270ms) : 265, 275
section Bailout
This PR (8271) - mean (274ms) : 268, 280
master - mean (270ms) : 266, 275
section CallTarget+Inlining+NGEN
This PR (8271) - mean (842ms) : 819, 864
master - mean (836ms) : 813, 859
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
andrewlock
force-pushed
the
andrew/ci/move-smoke-tests-to-nuke
branch
from
ba98d2f to
7134150
Compare
| } | ||
| } | ||
|
|
||
| // |
Collaborator
There was a problem hiding this comment.
probably we can remove this comment
| GenerateLinuxSmokeTestsArm64Matrix(); | ||
| GenerateLinuxChiseledInstallerSmokeTestsMatrix(); | ||
| GenerateLinuxChiseledInstallerArm64SmokeTestsMatrix(); | ||
| GenerateNukeSmokeTestsMatricies(); |
Member
Author
There was a problem hiding this comment.
True, it should be Matrices
| ForceRemove = true, | ||
| }; | ||
|
|
||
| for (var attempt = 1; attempt <= MaxRetries; attempt++) |
Collaborator
There was a problem hiding this comment.
Could we use the RetryAsync helper method here for consistency?
| HostConfig = new HostConfig | ||
| { | ||
| Init = true, | ||
| Binds = new List<string> |
Collaborator
There was a problem hiding this comment.
In the prvious method, we were using isWindowsScenario, but not here, should we?
Member
Author
There was a problem hiding this comment.
We don't (can't, I believe) run crash-test scenario on Windows I believe, but it doesn't hurt 👍 I actually thought I already made that change 😅
NachoEchevarria
approved these changes
Mar 6, 2026
Collaborator
NachoEchevarria
left a comment
NachoEchevarria
left a comment
There was a problem hiding this comment.
Amazing work. Thanks! While I totally understand that this needs to be a large PR, it's hard to analyze everything in depth. Still, if CI passes, I think that we are pretty covered.
andrewlock
force-pushed
the
andrew/ci/move-smoke-tests-to-nuke
branch
from
b758de1 to
a8f3d3b
Compare
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
Instead of most of the logic for running smoke tests being embedded in the yaml and bash inside yaml, move the building and running of smoke tests into Nuke.
Reason for change
The previous design had some downsides:
Implementation details
I initially tried to implement this over a year ago, using TestContainers, but tl;dr; I ran into a bunch of limitations that I couldn't get past (APIs that we needed, which just didn't exist, differences between windows/linux etc), so I abandoned it. Until 🤖 made exploring these things easier again!
The latest approach uses the https://github.com/dotnet/Docker.DotNet/ project, which provides a strongly-typed way to call the docker HTTP API (which is what TestContainers actually uses under the hood - it even uses this project). This made it much easier to convert the explicit steps that we are doing currently in bash/yaml/docker-compose to being simple C# methods.
At a high level, the implementation roughly follows what we have today, but it's tied much less to the azure devops infrastructure, as we just run our Nuke tasks in the same way we do today (i.e. directly on the box for Windows, in a docker container for Linux).
A high level overview:
GenerateVariablesstage still generates the matrix of variables, but it only needs to generate a category (e.g.LinuxX64Installer/WindowsFleetInstallerIis), and an associated scenario (the specific test, e.g.ubuntu, .NET 10, .deb).smoke_<x64|arm64|win|macos>_<installer|nuget|fleet>_tests. We can easily tweak this if we preferbuild.ps1 RunArtifactSmokeTests -SmokeTestCategory "LinuxX64Installer" -SmokeTestScenario "someScenario"That also means we can delete various things
Also includes a few tiny tweaks and cleanup (commented in the files as appropriate)
Test coverage
The same hopefully!? I've run the full sweet of tests several times, and spot checked various of the tests to make sure everything looks ok, and as far as I can tell, it does! Also temporarily modified the snapshots to confirm that causes everything to fail too
Other details
The big one which I didn't/couldn't easily convert is the macos smoke tests. These are written completely differently today, because they don't run in containers (which means we have to handle a whole bunch of different issues) and rather just duplicate a whole bunch of logic. It's probably not worth the effort to port them into Nuke at the moment, but I'm open to doing it in a follow up if people feel one way or the other.
The other thing is that I didn't move the "downloading of artifacts" into the nuke job, though technically we could, and it would make running locally even easier. My reason for not doing that was that it ties the nuke side to the azure devops side completely then, and if we rename an artifact in the yaml (for some reason) it's far more likely we'll forget it on the c# side.