Prepare MSTest 4.5.2 and MTP 2.5.2 release baselines

[Amaury Levé (Evangelink)]

Summary

• Bump MSTest from 4.5.1 to 4.5.2 and Microsoft.Testing.Platform from 2.5.1 to 2.5.2 on rel/4.5.
• Move the APIs included in MSTest 4.5.0 and Microsoft.Testing.Platform 2.5.0 from unshipped to shipped baselines, including classic-UWP adapter public APIs and PackagedApp Windows internal APIs.
• Move analyzer rules MSTEST0084 through MSTEST0089 under Release 4.5.0 and reset the analyzer/API unshipped tracking files.
• Normalize release-branch API entries that eng/mark-shipped.ps1 could not replace automatically; the final non-version rollover files match the result from Post-release: prepare main after MSTest 4.5 / MTP 2.5 #11765.

Validation

• .\build.cmd -bl — passed with 0 warnings and 0 errors.
• .\.dotnet\dotnet.exe run --project test\UnitTests\MSTest.Analyzers.UnitTests -f net8.0 --no-build -c Debug -bl:artifacts\log\Debug\AnalyzerReleaseTrackingTests.binlog -- --filter "FullyQualifiedName~AnalyzerReleaseTrackingTests" --minimum-expected-tests 3 --report-trx --report-trx-filename AnalyzerReleaseTrackingTests.trx --results-directory artifacts\TestResults\AnalyzerReleaseTrackingTests — passed 3/3 tests.
• Verified all 81 *API.Unshipped.txt files contain only #nullable enable.
• Verified all shipped API baselines contain no exact duplicate entries.

[github-actions]

Final test-triage resolution — Azure Pipelines build 1626892

Analysis is final (completed aggregate build; evidenceIncomplete is false).

Evidence review (107,000 normalized TRX/CTRF/JUnit records; 1 failed, 106,413 passed, 586 skipped):

• The only non-passing record is PackagedWinUI.PackagedWinUITestCases.RetryTestMethod_PassesOnSecondAppContainerHost, captured as a "failed" status in Windows_App_Model_Diagnostics_Attempt1 under .../TestResults/Retries/OrBmA/1/appcontainer-retry.trx (attempt 1).
• This is not a test-product defect or flake. It is the intentional first-attempt failure produced by a meta-test (PackagedWinUITests.cs, around line 689–711) that deliberately drives a nested AppContainer test host to fail once so it can assert MSTest's Retry extension activates a second host. The nested harness's attempt-2 TRX and the merged appcontainer-retry.trx both record RetryTestMethod_PassesOnSecondAppContainerHost as Passed, matching the meta-test's own assertions (Assert.AreEqual("Passed", ...) on the final and second-attempt outcomes).
• history.json candidate matching confirms this exact test name is the expected recurring Retry-diagnostics candidate (candidateArtifactFamilies: ["windows_app_model_diagnostics"]), consistent with a by-design retry exercise rather than a new regression. No prior-build history samples were available to compare against (builds: []), but the in-build evidence (attempt 1 fail → attempt 2 pass, by design) is sufficient on its own.
• diagnostics.json is empty — no crash/hang/dump evidence. timeline.compact.json has no failed/warned/retried pipeline records. The overall Azure build result is succeeded.

No issue is warranted: this is a one-off, by-design nested-failure assertion inside a passing meta-test, not a product or test defect, flake, crash, or slowdown regression.

Conclusion: Tests are healthy for this build. No further action needed.

🤖 Automated content by GitHub Copilot. Generated by the Pipeline Test Triage workflow. · copilot · auto · 38.5 AIC · ⌖ 6.54 AIC · ⊞ 9.7K