xUnit.net Integration with Mergify

This guide shows how to generate a JUnit report from your xUnit.net tests and upload it to Test Engine from your CI workflow.

How you get the report depends on the version of xUnit.net your test projects use: v2 projects run under dotnet test’s classic runner and take a JUnit logger, while v3 projects ship a JUnit reporter of their own.

Add the JUnit logger to your test project:

dotnet add package JunitXml.TestLogger

Then run your tests with it:

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

LogFilePath is resolved relative to the directory holding your test project’s .csproj, not to the directory you run dotnet test from. If your test project lives in a subdirectory, set the upload step’s report_path to the report’s path from the repository root, such as tests/Shop.Tests/junit.xml. With several test projects, each writes its own junit.xml next to its .csproj.

On the .NET 10 SDK, xUnit.net v3 projects run on Microsoft.Testing.Platform, which the JUnit logger above does not plug into. Use xUnit.net’s own reporter instead.

dotnet test runs Microsoft.Testing.Platform projects only once the global.json at your repository root opts in:

{
  "test": {
    "runner": "Microsoft.Testing.Platform"
  }
}

Then run each test project with the reporter turned on:

dotnet test --project tests/Shop.Tests --results-directory test-results/Shop.Tests --report-xunit-junit --report-xunit-junit-filename junit.xml

This writes test-results/Shop.Tests/junit.xml.

Run this command once per test project, each with its own --results-directory. When one dotnet test runs a whole solution, every project writes to the same report file, and the file ends up holding the tests of a single project.

The examples below use one v2 test project at the repository root, with the report in junit.xml. With v3, run your projects with the command above and upload test-results/*/junit.xml instead.

Run the tests in a step with an id, and let the upload step decide the job’s result:

- name: Run xUnit.net Tests
  id: tests
  continue-on-error: true
  run: dotnet test --logger "junit;LogFilePath=junit.xml"

- name: Mergify CI Upload
  if: success() || failure()
  uses: mergifyio/gha-mergify-ci@v27
  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 Test Engine 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.
• On pull requests from forks and from Dependabot, MERGIFY_TOKEN is empty and this step fails: skip it as shown in Pull Requests Without the Secret.

If you use a job matrix in your workflow (e.g., to test across multiple versions), every leg reports the same job name, because GitHub Actions gives them all one GITHUB_JOB. Set the job_name input so Test Engine can tell the reports apart:

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@v27
  with:
    job_name: example_matrix (${{ matrix.version }})
    token: ${{ secrets.MERGIFY_TOKEN }}
    report_path: junit.xml
    test_step_outcome: ${{ steps.tests.outcome }}

To benefit from Test Engine 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 then decides whether the job passes or fails, taking quarantined tests into account.

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.

With continue-on-error: true, the job’s result comes from the upload step. On pull requests from forks and from Dependabot, MERGIFY_TOKEN is empty and the upload step has to be skipped: add the step that fails the job when the tests failed and nothing was uploaded, as shown in pull requests without the secret.

steps:
  - label: "Run tests"
    command: <your test command>
    plugins:
      - mergifyio/mergify-ci#v8:
          action: junit-process
          report_path: junit.xml

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, each variation reports its own step label as its job name, so the variations are already distinct. Set the job_name plugin property when the label is not the name you want Test Engine to file the reports under:

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

When using the Buildkite plugin for Test Engine 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
exit_code=0
dotnet test --logger "junit;LogFilePath=junit.xml" || exit_code=$?
mergify ci junit-process \
  --test-exit-code "$exit_code" \
  junit.xml

Key Points:

• MERGIFY_TOKEN: Export this environment variable with your Mergify application key so junit-process can authenticate to the API.
• || exit_code=$?: CI shells run with -e, so a failing test command on its own line would end the script before the upload. This form keeps going and records the code. The script needs bash for set -o pipefail: on Jenkins, whose sh steps often run dash, start it with #!/bin/bash.
• --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.
• junit-process exits last, so its status becomes the step's. Quarantine depends on that: it exits 0 when every failure it found is quarantined, and 1 when one is not. Re-exiting with the test runner's own code would fail the step whatever quarantine decided.
• The branch quarantine is evaluated against is detected from your CI provider, falling back to the checked-out branch. Pass --tests-target-branch <branch> only to override it.

With xUnit.net v2 and the JUnit logger, Test Engine names each test by its class’s full name, then a dot and its method: the fact AddsAnItem of the class Shop.Tests.CartTest is reported as Shop.Tests.CartTest.AddsAnItem. Each case of a theory is a test of its own, named after its arguments: Shop.Tests.CartTest.Positive(n: 1).

xUnit.net v3’s reporter writes the class’s full name into each test’s name as well, so names repeat the class: Shop.Tests.CartTest.Shop.Tests.CartTest.AddsAnItem. These names are as stable as the v2 ones. Moving from v2 to v3 changes every name, though, so your tests start new histories in Test Engine.

Renaming a namespace, a class or a method starts a new history for the tests it holds. Tests with a Skip reason are reported as skipped.

After pushing these changes:

1. Your CI workflow runs your xUnit.net tests.
2. The logger, or xUnit.net v3’s reporter, writes the JUnit report.
3. Mergify uploads the report to Test Engine.

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

• Zero tests ran with xUnit.net v3: --logger is an option of the classic runner. On Microsoft.Testing.Platform, the run fails without running any test. Use --report-xunit-junit instead.

• Tests missing with xUnit.net v3: if several test projects share a results directory, they overwrite each other’s report. Give each project its own --results-directory.

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