Dart Integration with Mergify
Report your test results from Dart's test package to Mergify
This guide shows how to generate a JUnit report from your Dart tests, written
with the test package, and upload it to
Test Engine from your CI workflow.
For a Flutter app, see the Flutter guide.
Generate a JUnit report with Dart
Section titled Generate a JUnit report with Dartdart test has no JUnit output of its own. It writes its results as JSON,
which the junitreport package
converts to JUnit XML.
Install the converter once on the machine that runs your tests:
dart pub global activate junitreportRun your tests with a JSON file reporter. --file-reporter writes the JSON to
a file and keeps the usual output in your terminal:
dart test --file-reporter json:test-results.jsonThen convert the JSON to JUnit XML:
dart pub global run junitreport:tojunit --input test-results.json --output junit.xmlRun the conversion even when tests fail: dart test exits with a non-zero
status then, and the conversion is what writes the report you upload.
Update your CI workflow
Section titled Update your CI workflowGitHub Actions
Section titled GitHub ActionsRun the tests in a step with an id, convert their results, and let the
upload step decide the job’s result:
- name: Install junitreport run: dart pub global activate junitreport
- name: Run Dart Tests id: tests continue-on-error: true run: dart test --file-reporter json:test-results.json
- name: Convert the results to JUnit run: dart pub global run junitreport:tojunit --input test-results.json --output 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 anid(such astests) to your test runner step and update thesteps.<id>.outcomereference to match. -
On pull requests from forks and from Dependabot,
MERGIFY_TOKENis 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.
Buildkite
Section titled BuildkiteRun the conversion in your step’s command, after the tests, so it runs
whatever their outcome, and exit with the tests’ status:
dart pub global activate junitreportstatus=0dart test --file-reporter json:test-results.json || status=$?dart pub global run junitreport:tojunit --input test-results.json --output junit.xmlexit $statussteps: - label: "Run tests" command: <your test command> plugins: - mergifyio/mergify-ci#v8: action: junit-process report_path: junit.xmlKey Points:
-
The plugin runs in the
post-commandhook, 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.xmlWhen 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.
Any CI (Mergify CLI)
Section titled Any CI (Mergify CLI)Install the Mergify CLI in your pipeline and export
MERGIFY_TOKEN. Run the conversion between your tests and
mergify ci junit-process:
set -o pipefailexit_code=0dart test --file-reporter json:test-results.json || exit_code=$?dart pub global run junitreport:tojunit --input test-results.json --output junit.xmlmergify ci junit-process \ --test-exit-code "$exit_code" \ junit.xml--test-exit-code passes the tests’ status to Mergify, which uses it to catch
a run that crashed but left a clean report behind. junit-process exits last,
so its status, which accounts for quarantined tests, becomes the step’s.
Test names
Section titled Test namesTest Engine names each test by its file’s path without _test.dart, dotted,
then a dot and its groups and description, joined with spaces: the test
'adds an item' inside group('add()') inside group('Cart') of
test/cart_test.dart is reported as test.cart.Cart add() adds an item.
Moving or renaming the file, a group or the test starts a new history for it.
Tests with a skip argument are reported as skipped.
Verify and review in Test Engine
Section titled Verify and review in Test EngineAfter pushing these changes:
- Your CI workflow runs your Dart tests.
dart testwrites its results totest-results.json, andtojunitconverts them tojunit.xml.- 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.
Troubleshooting tips
Section titled Troubleshooting tipsReport not found when tests fail: check that the conversion runs after a failed test run, as in the examples above.
- 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_TOKENis 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.
Was this page helpful?
Thanks for your feedback!