Rust Integration with Mergify

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

Rust’s built-in test framework doesn’t output JUnit XML reports. You can either run your tests through cargo-nextest, which writes JUnit XML itself, or keep cargo test and convert its output with cargo2junit.

cargo-nextest is a test runner that writes JUnit XML natively. It has no command-line flag for it: you enable JUnit output per profile in your .config/nextest.toml.

cargo install cargo-nextest

Add a junit section to the profile you use in CI:

[profile.ci.junit]
path = "junit.xml"

Then run that profile:

cargo nextest run --profile ci

The path is relative to the profile’s output directory, so this writes target/nextest/ci/junit.xml.

cargo2junit converts cargo’s JSON test output into JUnit XML.

cargo install cargo2junit

It reads that JSON on standard input, so cargo test has to be asked for JSON rather than its usual human-readable output. That option is nightly-only, but RUSTC_BOOTSTRAP=1 unlocks it on a stable toolchain:

RUSTC_BOOTSTRAP=1 cargo test -- -Z unstable-options --format json --report-time | cargo2junit > junit.xml

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

For example, in your workflow file:

- name: Install cargo-nextest
  uses: taiki-e/install-action@nextest

- name: Run Rust Tests and Generate JUnit Report
  id: tests
  continue-on-error: true
  run: cargo nextest run --profile ci

- name: Mergify CI Upload
  if: success() || failure()
  uses: mergifyio/gha-mergify-ci@v26
  with:
    token: ${{ secrets.MERGIFY_TOKEN }}
    report_path: target/nextest/ci/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: target/nextest/ci/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), 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@v26
  with:
    job_name: example_matrix (${{ matrix.version }})
    token: ${{ secrets.MERGIFY_TOKEN }}
    report_path: target/nextest/ci/junit.xml
    test_step_outcome: ${{ steps.tests.outcome }}

Alternative approach using cargo2junit, which writes wherever you redirect it:

- name: Install cargo2junit
  run: cargo install cargo2junit

- name: Run Rust Tests and Generate JUnit Report
  id: tests
  continue-on-error: true
  run: RUSTC_BOOTSTRAP=1 cargo test -- -Z unstable-options --format json --report-time | cargo2junit > junit.xml

- name: Mergify CI Upload
  if: success() || failure()
  uses: mergifyio/gha-mergify-ci@v26
  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.

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 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#v8:
          action: junit-process
          report_path: target/nextest/ci/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: target/nextest/ci/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: target/nextest/ci/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
cargo nextest run --profile ci
exit_code=$?
mergify ci junit-process \
  --test-exit-code "$exit_code" \
  target/nextest/ci/junit.xml

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.
• 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.
• 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 Rust tests.
2. A JUnit report is generated at target/nextest/ci/junit.xml, or wherever you redirect cargo2junit.
3. The Mergify CI action 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.

• Tool Installation: Ensure cargo-nextest or cargo2junit is properly installed before running tests.
• Output Format: Verify that the chosen tool generates valid JUnit XML format.
• 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.