Repository navigation
Add the new TerminalTestReporter partials to dotnet/sdk's vendored-files manifest #10390
Description
Activity
Opened the SDK-side PR: dotnet/sdk#55563 — adds the four new paths (
.Coverage.cs,.FlakyTests.cs,.SlowestTests.cs,.TestDiscovery.cs) to thedotnet-test-terminal-reporterentry ineng/vendored-files.jsonwith"scope": "reporter partial", baselined at testfxmainf935d2d3. No existing baseline is touched, so the SDK's open drift issues (dotnet/sdk#55472 for.Summary.cs, dotnet/sdk#55473 for.TestCompletion.cs) are unaffected.One finding worth recording here, because it makes this issue more important than "a bookkeeping gap":
The SDK's hard-forked
TerminalTestReporter.cscontains noAppendCoverageSummary,AppendFlakyTests,AppendSlowestTestsorAppendRetrySummaryLines— that work is unported. And the.Summary.csdrift issue cannot surface it. The drift bot renders a unified diff between two endpoints, and that code was added toSummary.csafter the SDK's baseline (dba319b2) and then moved out into the new partials by #10387. So it is absent from both endpoints and appears nowhere in the diff. Added-then-moved content is structurally invisible to endpoint diffing.I did not try to encode that backlog in the baseline SHAs — the manifest schema has no "never synced" state, and inventing one would render a misleading diff. Instead the PR records it in the entry's
notes, which the bot already renders into every drift issue for this entry, so it lands in front of whoever picks up dotnet/sdk#55472.The "track the folder rather than individual files" idea in the Action section is the real fix and would have prevented this; I left it out of the PR to keep it reviewable, and called it out there instead.
- added a commit that references this issue
on Aug 3, 2026 Handled by dotnet/sdk#55564, merged on August 3, 2026. The SDK manifest now tracks all four new TerminalTestReporter partials while preserving the existing source indices. Remaining reporter reconciliation work is tracked separately by dotnet/sdk#55472 and dotnet/sdk#55473.
Context
PR #10387 splits
src/Platform/Microsoft.Testing.Platform/OutputDevice/Terminal/TerminalTestReporter.Summary.cs(715 lines) into focused partial files, adding four new paths in that folder:TerminalTestReporter.Coverage.csTerminalTestReporter.TestDiscovery.csTerminalTestReporter.FlakyTests.csTerminalTestReporter.SlowestTests.csNothing needed to change on the testfx side:
TerminalReporterContract.propsincludes the reporter source via a$(MSBuildThisFileDirectory)*.csglob with a two-entryExclude, so the new files are picked up automatically. The standaloneMicrosoft.Testing.Platform.TerminalReporterContract.UnitTestsconsumer compiles them with 0 warnings.Problem
As
TerminalReporterContract.propsdocuments, this reporter source is hard-forked intodotnet/sdk, which tracks it ineng/vendored-files.jsonand runs a scheduled workflow that opens an issue whenever the upstream files change.That manifest enumerates each partial individually rather than globbing the folder. Under the
dotnet-test-terminal-reporterentry it currently listsTerminalTestReporter.cs,.ErroredAssemblies.cs,.Formatting.ControlCharacters.cs,.Formatting.cs,.Handshake.cs,.Lifecycle.cs,.Messaging.cs,.Summary.csand.TestCompletion.cs, each with"scope": "reporter partial".The four new paths are absent from that list. Until they are added, future edits to the coverage, discovery, flaky-test and slowest-test rendering are invisible to the SDK's drift detector — including bug fixes that the SDK's hard-forked copy would want.
The shrinking of
TerminalTestReporter.Summary.cs(−467 lines) will trip the drift workflow, so this should get a human's attention on the next run. This issue exists so it isn't silently closed as "just a move".Action
Add the four new paths to the
dotnet-test-terminal-reporterentry indotnet/sdk'seng/vendored-files.json, with"scope": "reporter partial"to match the existing entries, and port the split (or fold the moved code into the SDK's singleTerminalTestReporter.cs, which is how it already reconciles our partials).Longer term it may be worth considering whether that manifest entry can track the folder rather than individual files, so a future partial split doesn't need a coordinated change.