Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
72 changes: 72 additions & 0 deletions azure-pipelines-retry-sample.yml
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure how to do that.

Maybe @ViktorHofer or @akoeplinger could help?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Original file line number Diff line number Diff line change
@@ -0,0 +1,72 @@
# Azure Pipeline for testing the RetryExtensionSample
# This pipeline builds and runs the RetryExtensionSample to verify it works correctly

trigger:
branches:
exclude:
- *

pr:
branches:
include:
- main
- rel/*

variables:
- name: _TeamName
value: MSTest
- name: SampleProjectPath
value: samples/public/mstest-runner/RetryExtensionSample

stages:
- stage: TestRetrySample
displayName: Test Retry Extension Sample
jobs:
- job: Windows
displayName: Windows
pool:
name: NetCore-Public
demands: ImageOverride -equals windows.vs2022preview.amd64.open
steps:
- task: UseDotNet@2
displayName: 'Install .NET SDK'
inputs:
packageType: sdk
useGlobalJson: true
workingDirectory: $(Build.SourcesDirectory)

- task: DotNetCoreCLI@2
displayName: 'Restore sample project'
inputs:
command: restore
projects: '$(SampleProjectPath)/RetryExtensionSample.csproj'
feedsToUse: config
nugetConfigPath: '$(SampleProjectPath)/../../NuGet.config'

- task: DotNetCoreCLI@2
displayName: 'Build sample project'
inputs:
command: build
projects: '$(SampleProjectPath)/RetryExtensionSample.csproj'
arguments: '--configuration Release --no-restore'

- task: PowerShell@2
displayName: 'Run sample with retry (expect success)'
inputs:
targetType: 'inline'
script: |
cd $(SampleProjectPath)
dotnet run --configuration Release --no-build -- --retry-failed-tests 3
workingDirectory: $(Build.SourcesDirectory)
failOnStderr: false

- task: PublishTestResults@2
displayName: 'Publish Test Results'
inputs:
testResultsFormat: 'VSTest'
testResultsFiles: '**/TestResults/**/*.trx'
searchFolder: '$(Build.SourcesDirectory)/$(SampleProjectPath)'
mergeTestResults: true
failTaskOnFailedTests: false
testRunTitle: 'Retry Extension Sample Tests'
condition: always()
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
namespace RetryExtensionSample;

[TestClass]
public class FlakySampleTests
{
[TestMethod]
public void FlakyTest_FailsFirstTime_PassesOnRetry()
{
if (Environment.GetCommandLineArgs().Any(arg => arg.Contains("Retries") && !arg.EndsWith("2")))
{
Assert.Fail("Simulated failure on first execution");
}
}

[TestMethod]
public void NormalTest_AlwaysPasses()
{
}
}
41 changes: 41 additions & 0 deletions samples/public/mstest-runner/RetryExtensionSample/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# Microsoft.Testing.Extensions.Retry Sample

This sample demonstrates how to use the `Microsoft.Testing.Extensions.Retry` extension to automatically retry failed tests. This is useful for handling flaky tests that might fail intermittently due to timing issues, network conditions, or other transient failures.

## What is Microsoft.Testing.Extensions.Retry?

The Retry extension is a testing platform-level feature that allows you to automatically retry tests that fail. When enabled, if a test fails, the entire test suite will be re-run up to a specified number of times until all tests pass or the maximum retry count is reached. This extension is compatible with any test framework that supports Microsoft.Testing.Platform, and is not specific to MSTest.

### Important: Difference from `[Retry]` Attribute

1. **`Microsoft.Testing.Extensions.Retry`** (this sample): A **platform-level** extension that retries the **entire test suite** when any test fails. Activated via `--retry-failed-tests` command-line option.
2. **`[Retry]` attribute**: A **framework-level** attribute that retries individual test methods. Applied directly to test methods like `[TestMethod]` and `[Retry(3)]`. This is specific to MSTest.

Use the platform-level retry extension when you want to handle environment-level failures that affect multiple tests. Use the `[Retry]` attribute when specific test methods are known to be flaky.

## Key Features

- Automatically retries failed tests
- Configurable retry count
- Failure threshold policies (max percentage, max tests count)
- Works at the test suite level

## How to Use

### 1. Add the Package Reference

Add the `Microsoft.Testing.Extensions.Retry` package to your project:

```xml
<PackageReference Include="Microsoft.Testing.Extensions.Retry" Version="$(MicrosoftTestingPlatformVersion)" />
```

### 2. Run Tests with Retry Enabled

Run your tests with the `--retry-failed-tests` command-line option:

```bash
dotnet test --project RetryExtensionSample.csproj --retry-failed-tests 3
```

This will retry failed tests up to 3 times.
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
<Project Sdk="MSTest.Sdk">

<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
<EnableMicrosoftTestingExtensionsRetry>true</EnableMicrosoftTestingExtensionsRetry>
</PropertyGroup>

</Project>