JUnit Integration with Mergify

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

Maven and Gradle both write JUnit XML reports when they run your tests, with no plugin to add. What changes between them is where the reports land and how they name your tests (see Test names).

Maven’s Surefire plugin runs your unit tests and writes one report per test class in each module’s target/surefire-reports/:

mvn -B -fae test

-fae (fail at end) keeps Maven going after a module’s tests fail, so the other modules run their tests and write their reports too. In a multi-module build, upload the reports of every module with **/target/surefire-reports/TEST-*.xml.

If you run integration tests with the Failsafe plugin, run mvn -B -fae verify instead, and upload **/target/failsafe-reports/TEST-*.xml as well. Keep the TEST- prefix in that pattern: Failsafe also writes a failsafe-summary.xml in the same directory, which is not a JUnit report, and an upload that includes it fails.

Gradle’s test task writes JUnit XML reports without any extra configuration. If your tests run on JUnit 5, enable the platform in your build.gradle:

test {
    useJUnitPlatform()
}

Run tests with:

./gradlew test --continue

--continue keeps Gradle going after a project’s tests fail, so the other projects run their tests and write their reports too. Each project writes one report per test class in its build/test-results/test/. A test task of your own, such as integrationTest, writes to a directory named after it, build/test-results/integrationTest/; upload **/build/test-results/**/*.xml to cover them all.

The examples below use a Maven build with several modules. For Gradle, run ./gradlew test --continue and upload **/build/test-results/**/*.xml instead.

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

- name: Run JUnit Tests
  id: tests
  continue-on-error: true
  run: mvn -B -fae test

- name: Mergify CI Upload
  if: success() || failure()
  uses: mergifyio/gha-mergify-ci@v27
  with:
    token: ${{ secrets.MERGIFY_TOKEN }}
    report_path: "**/target/surefire-reports/TEST-*.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/surefire-reports/TEST-*.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: "**/target/surefire-reports/TEST-*.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: "**/target/surefire-reports/TEST-*.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/surefire-reports/TEST-*.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/surefire-reports/TEST-*.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.

Quote the pattern, so that mergify ci junit-process expands it rather than the shell: without globstar, bash reads ** as * and misses the reports at other depths.

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
mvn -B -fae test || exit_code=$?
mergify ci junit-process \
  --test-exit-code "$exit_code" \
  "**/target/surefire-reports/TEST-*.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: the pull request's base branch, falling back to the branch built. Pass --tests-target-branch <branch> to override it, or to name one where your provider reports neither — with no branch to look tests up on, quarantine is off for the run and every failure blocks.

Test Engine names each test by its class’s full name, then a dot and the name the build tool reports for it. Maven and Gradle report different names for the same test, so moving a project from one to the other starts new histories in Test Engine.

• @Test void addsAnItem() in com.example.CartTest: Maven reports com.example.CartTest.addsAnItem, Gradle com.example.CartTest.addsAnItem().

• The same test with @DisplayName("adds an item"): Maven reports com.example.CartTest.addsAnItem, Gradle com.example.CartTest.adds an item.

• The first case of @ParameterizedTest void positive(int n): Maven reports com.example.CartTest.positive(int)[1], Gradle com.example.CartTest.[1] 1.

• @Test void pays() in the @Nested class Checkout: Maven reports com.example.CartTest$Checkout.pays, Gradle com.example.CartTest$Checkout.pays().

With Gradle, a parameterized test’s cases are named by the test’s display name pattern, which leaves out the method’s name by default. Give the pattern the method’s name, so the cases of two parameterized tests in one class keep separate names:

@ParameterizedTest(name = "positive({0})")
@ValueSource(ints = {1, 2})
void positive(int n) { /* ... */ }

The first case is then reported as com.example.CartTest.positive(1).

Renaming a class or a method, or with Gradle a display name, starts a new history for the tests it holds. Tests marked with @Disabled are reported as skipped.

After pushing these changes:

1. Your CI workflow runs your JUnit tests.
2. Maven or Gradle writes a report per test class.
3. Mergify uploads the reports to Test Engine.

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

• Upload fails with Failsafe: an upload pattern such as target/failsafe-reports/*.xml picks up failsafe-summary.xml. Match TEST-*.xml instead.

• Reports of one module only: without -fae, Maven stops at the first module whose tests fail, and the modules after it write no report. Gradle does the same without --continue.

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