MSTest Integration with Mergify

This guide shows how to generate JUnit reports from your MSTest tests and upload them to Test Insights using your CI workflow.

MSTest can generate JUnit-compatible XML reports using the built-in logger or third-party tools. The dotnet test command supports various loggers including JUnit format.

Install the JUnit test logger:

dotnet add package JunitXml.TestLogger

Run tests with JUnit output:

dotnet test --logger "junit;LogFilePath=junit.xml"

You can also generate TRX files and convert them to JUnit:

dotnet test --logger trx --results-directory ./TestResults

Then use a tool like trx2junit to convert:

dotnet tool install -g trx2junit
trx2junit ./TestResults/*.trx

Add the JUnit logger package to your test project:

<PackageReference Include="JunitXml.TestLogger" Version="6.1.0" />

Then run:

dotnet test --logger junit

You can combine multiple loggers:

dotnet test --logger "console;verbosity=detailed" --logger "junit;LogFilePath=junit.xml"

After generating the JUnit report, add a step to upload the results to CI Insights using the mergifyio/gha-mergify-ci action.

For example, in your workflow file:

- name: Run MSTest Tests and Generate JUnit Report
  continue-on-error: true
  run: dotnet test --logger "junit;LogFilePath=junit.xml"

- name: Mergify CI Upload
  if: success() || failure()
  uses: mergifyio/gha-mergify-ci@v8
  with:
    token: ${{ secrets.MERGIFY_TOKEN }}
    report_path: junit.xml
    test_step_outcome: ${{ steps.tests.outcome }}

Key Points:

• if: success() || failure(): Runs the upload step even if tests fail, ensuring CI Insights has the full report.
• report_path: junit.xml: Points to where your JUnit file is located. Make sure it matches the path you set in your CI job.
• test_step_outcome: ${{ steps.tests.outcome }}: Passes the test runner step's outcome so Mergify can detect silent failures where the runner crashed but the JUnit report appears clean. Add an id (such as tests) to your test runner step and update the steps.<id>.outcome reference to match.

If you use a job matrix in your workflow (e.g., to test across multiple versions), ensure you set the job_name input (or MERGIFY_JOB_NAME environment variable) so CI Insights can properly distinguish reports for each matrix job.

For example, with:

jobs:
  example_matrix:
    strategy:
      matrix:
        version: [10, 12, 14]

Your upload step should look like:

- name: Mergify CI Upload
  if: success() || failure()
  uses: mergifyio/gha-mergify-ci@v8
  with:
    job_name: example_matrix (${{ matrix.version }})
    token: ${{ secrets.MERGIFY_TOKEN }}
    report_path: junit.xml
    test_step_outcome: ${{ steps.tests.outcome }}

In order to benefit from Test Insights Quarantine, you need to add continue-on-error: true in your GitHub Actions step that executes your tests and generates the JUnit file. The step running the gha-mergify-ci action will determine the success or failure conclusion, considering quarantined tests.

You should also pass test_step_outcome: ${{ steps.tests.outcome }} to the step that runs mergifyio/gha-mergify-ci (where tests is the id of your test runner step) to detect silent failures where the test runner crashed but the JUnit report appears clean. Without this input, a crash that produces a partial or empty report could be mistakenly treated as a success.

steps:
  - label: "Run tests"
    command: <your test command>
    plugins:
      - mergifyio/mergify-ci#v1:
          action: junit-process
          report_path: junit.xml
          token: "${MERGIFY_TOKEN}"

Key Points:

• The plugin runs in the post-command hook, so it uploads results after your tests finish, even if they fail.
• report_path: junit.xml: Points to where your JUnit file is located. Make sure it matches the path you set in your test configuration.
• Silent failure detection is automatic: the plugin reads the step's exit code to detect cases where the test runner crashed but the JUnit report appears clean.

If you use a build matrix in your pipeline, set the job_name property so CI Insights can properly distinguish reports for each matrix variation.

For example:

steps:
  - label: "Tests ({{matrix}})"
    matrix:
      - "3.10"
      - "3.11"
      - "3.12"
    command: <your test command>
    plugins:
      - mergifyio/mergify-ci#v1:
          action: junit-process
          job_name: "Tests ({{matrix}})"
          report_path: junit.xml
          token: "${MERGIFY_TOKEN}"

When using the Buildkite plugin for Test Insights Quarantine, the plugin automatically detects test failures using the step’s exit code. No extra configuration is needed.

The mergifyio/mergify-ci plugin runs in the post-command hook and reads BUILDKITE_COMMAND_EXIT_STATUS to detect silent failures where the test runner crashed but the JUnit report appears clean.

Install the Mergify CLI in your pipeline and export MERGIFY_TOKEN. Run mergify ci junit-process after your tests:

set -o pipefail
dotnet test --logger "junit;LogFilePath=junit.xml"
exit_code=$?
mergify ci junit-process \
  --test-exit-code "$exit_code" \
  junit.xml
exit $exit_code

Key Points:

• MERGIFY_TOKEN: Export this environment variable with your Mergify application key so junit-process can authenticate to the API.
• --test-exit-code "$exit_code": Passes the test runner's exit code so Mergify can detect silent failures where the runner crashed but the JUnit report appears clean.
• On CI systems other than GitHub Actions, also pass --tests-target-branch <branch> so the command knows which branch to compare against for quarantine decisions.

After pushing these changes:

1. Your GitHub Actions workflow will execute your MSTest tests.
2. A JUnit report (junit.xml) is generated.
3. The Mergify CI action uploads the report to Test Insights.

You can then review your test results, including any failures or flaky tests, directly in the Test Insights dashboard.

• Logger Package: Ensure the JunitXml.TestLogger package is added to your test project.
• .NET Version: Make sure you’re using a compatible version of .NET that supports the test loggers.
• The CLI provides information about the upload. Check the logs in GitHub Actions.
• File Paths: Double-check that the output file matches the path used in report_path.
• Permissions: Make sure the MERGIFY_TOKEN is valid and setup in your GitHub Actions secrets as explained in the docs.
• Workflow Conditions: If your step is not running, confirm the if condition is actually triggered in your job.