Add public sample for Microsoft.Testing.Extensions.Retry extension

[Copilot]

Adds a runnable sample demonstrating the platform-level retry extension with a test that fails initially and passes on retry.

Changes

• RetryExtensionSample/ - New sample project under samples/public/mstest-runner/
  • FlakySampleTests.cs - Test using static counter to fail first run, pass on retry
  • Program.cs - Entry point registering retry provider via AddRetryProvider()
  • README.md - Clarifies distinction between platform-level retry (retries entire suite) vs [Retry] attribute (retries individual methods)
• azure-pipelines-retry-sample.yml - New Azure Pipeline for CI/CD
  • Runs the sample on Windows and Linux
  • Tests without retry (expects failure) and with retry (expects success)
  • Publishes test results to Azure DevOps

Usage

# Without retry - fails
dotnet run --project RetryExtensionSample.csproj

# With retry - succeeds on second attempt
dotnet run --project RetryExtensionSample.csproj -- --retry-failed-tests 3

Expected output shows retry in action:

Test execution count: 1
First execution - simulating failure
Tests suite failed, total failed tests: 1, exit code: 2, attempt: 1/4

Test execution count: 2
Test passed on retry!
Tests suite completed successfully in 2 attempts

[!WARNING]

Original prompt

Add public sample for Microsoft.Testing.Extensions.Retry extension where a test fails then passes on retry.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Youssef1313]

@copilot Create new Azure Pipeline that runs the new sample, and publishes test results.

[Copilot]

@copilot Create new Azure Pipeline that runs the new sample, and publishes test results.

Created azure-pipelines-retry-sample.yml that:

• Runs the sample on Windows and Linux
• Tests without retry (expects failure) and with retry (expects success)
• Publishes test results to Azure DevOps
• Triggers on changes to the sample directory

Commit: e326e9c

[Youssef1313]

@nohwnd What do you think about running this pipeline in PRs as an "optional" pipeline?

[nohwnd]

If we put a failing scenario in such pipeline (e.g. where we show how hangdump works, we want the run to fail), will it show up as failing / warning for us. How do we filter out that kind of "noise" while still making it useful.

And how do we make it maintainable? If the hang dump pipeline normally shows red, how do we make sure we keep it working, instead of it failing with some other error that is unexpected?

[Youssef1313]

@nohwnd This is for retry, not hangdump.
But yeah your question still applies for retry as well.

I was thinking of it mostly as we manually keep monitoring that publishing TRX with retries work on AzDO.

[nohwnd]

Can one pipeline look at other pipeline? feels to me like something we "normally" do in dotnet and vs biulds, where the run kicks off another pipeline and then somehow monitors the results of the other pipeline. In that case with a bit of logic our "main" pipeline would be able to kick off "retry-sample" and then "retry-sample-validate" would carry out some check that ensures "retry-sample" worked. It could be similar for hang dump.

We can even write a set of tests that would look at the other pipelines from one pipeline probably. So we don't report on 100 different pipelines.

[Youssef1313]

Not sure how to do that.

Maybe @ViktorHofer or @akoeplinger could help?

[akoeplinger]

I'm not aware of an easy way to trigger another pipeline as part of a build or look at results, you'd need to use AzDO REST APIs for that.