View as Markdown

Vitest Integration with CI Insights

Report your test results from Vitest to CI Insights


This guide shows how to configure Vitest to produce JUnit reports and upload them to CI Insights within a GitHub Actions workflow.

Generate a JUnit Report with Vitest

Section titled Generate a JUnit Report with Vitest

By default, Vitest doesn’t generate JUnit-format test results. You need to enable it in your vite.config.ts or vitest.config.ts.

This is documenteded on vitest website.

For example:

export default defineConfig(({ mode }) => {
return {
test: {
reporters: ['default', 'junit'],
outputFile: './junit.xml',
includeConsoleOutput: true,
},
};
});

Key Options:

  • reporters: ['default', 'junit']: Tells Vitest to generate JUnit reports alongside the standard console output.

  • outputFile: './junit.xml': Sets the path where Vitest writes the test results (you can rename or relocate as you prefer).

  • includeConsoleOutput: true: Ensures console logs are captured in the final report.

Update Your GitHub Actions Workflow

Section titled Update Your GitHub Actions Workflow

Once you have the JUnit file produced by Vitest, add a step to upload these results to CI Insights via the mergifyio/gha-mergify-ci action.

In the workflow file where vitest is launched, after running npm run test (or similar), include a step like:

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

In order to benefit from CI 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.

Verify and Review in CI Insights

Section titled Verify and Review in CI Insights

After pushing these changes:

  1. Your GitHub Actions workflow will run tests with Vitest.
  2. Vitest generates junit.xml.
  3. The Mergify CI action uploads that file to CI Insights.

You can then see your test results, including failures and flaky tests, directly in the CI Insights dashboard.

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

Was this page helpful?