GitHub Actions test results

Depot can ingest JUnit XML test reports from your GitHub Actions jobs and display them in the Depot dashboard. Add the depot/test-report-action to your workflow after your test step, pointed at your test runner's JUnit XML output.

The action is supported on jobs using Depot GitHub Actions runners. Unsupported runner environments log a warning and skip upload.

Depot can also use the timing data in these reports to balance parallel test jobs. See Split tests by timing for setup, including the GitHub Actions runner shard inputs.

Report test results from a GitHub Actions job

Add the depot/test-report-action action to your workflow after the step that runs your tests. Point it at the directory, file, or glob containing the JUnit XML output:

jobs:
  test:
    runs-on: depot-ubuntu-24.04
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: |
          mkdir -p test-results
          pnpm exec vitest run \
            --reporter=default \
            --reporter=junit \
            --outputFile.junit=test-results/junit.xml
      - name: Report tests
        uses: depot/test-report-action@v1
        if: ${{ !cancelled() }}
        with:
          path: test-results/

id-token: write lets the action authenticate to Depot using GitHub's OIDC token. Set it on the job or at the workflow level when using Depot GitHub Actions runners. Workflow authors do not pass a token to this action.

if: ${{ !cancelled() }} makes sure the action runs even when an earlier step (like your tests) fails, which is when you most want the results uploaded. The action still skips when the job is cancelled.

path: is the path or glob the action uses for JUnit XML files. When path points at a directory, the action uploads XML files under that directory recursively. Newline-separated values are valid if you want to report multiple paths in one step. See the action's README for examples.

Supported JUnit XML producers

Depot accepts JUnit XML directly, so most test runners work when they can write that format. These runners, adapters, and more work out of the box:

Node.js built-in test runner (node:test)
Vitest
Jest (via jest-junit)
Playwright
pytest
RSpec
gotestsum

Reporting multiple test suites from one job

If a job produces JUnit XML in more than one location, pass them all to a single step via the path: input:

- name: Report tests
  uses: depot/test-report-action@v1
  if: ${{ !cancelled() }}
  with:
    path: |
      test-results/unit.xml
      test-results/integration/
      test-results/e2e/**/*.xml

If the same job calls the action more than once, use one step per upload and set the action's key: input to a unique value so each upload invocation can be deduplicated separately. Test suites are still derived from the JUnit XML contents.

- name: Report unit tests
  uses: depot/test-report-action@v1
  if: ${{ !cancelled() }}
  with:
    key: unit
    path: test-results/unit/
- name: Report integration tests
  uses: depot/test-report-action@v1
  if: ${{ !cancelled() }}
  with:
    key: integration
    path: test-results/integration/

If key: isn't set, the action falls back to $GITHUB_ACTION, then to default.

View results in the Depot dashboard

You can view test results in the Depot dashboard in three places: inline on each job, on a per-job test results page, and on an org-wide analytics dashboard that tracks failure rates, flaky tests, slow tests, and recurring failures over time.

Inline on a job

From the GitHub Actions page, open a job to see its detail view. When test results have been reported for the job, a test results section appears in the job's detail panel with pass/fail/error/skip counts and a short list of failing tests, each with its failure details inlined. Click the section link (View failures, View errors, or View all depending on what's reported) to open the full results page.

Per-job test results page

The per-job test results page (linked from the inline section above) lists every test in the most recent run of the job. Use the filters at the top to narrow by status (passed, failed, errored, skipped) and search by test name, suite, class, or file.

Each failing row expands to show the failure message, failure type, stack trace, and captured stdout and stderr.

The page includes the following historical context for each test:

Recurring: A badge showing how often this test has failed across recent jobs for the same test identity.
Latest occurrence: Marks the row as the most recent run where the test had this status.
View latest failure: A link to the most recent failure when you're viewing an older one.
Passed on rerun: A badge indicating a failure that was resolved by a later rerun on the same SHA.

Org-wide analytics

For trends across all your test runs, open the Test Results Analytics page. The page analyzes test results ingested from GitHub Actions jobs and Depot CI jobs in the organization, so you can step out of a single job and look for patterns over time. Use the CI filter at the top of the page to scope the dashboard to GitHub Actions only, or compare GitHub Actions against Depot CI side by side.

Some analytics are more complete for Depot CI because Depot has more run and attempt metadata available. In particular, the Possibly flaky tests card is based on Depot CI attempts.

Common reasons to open the analytics page:

A test is failing and you want to know if it's a one-off or a recurring problem. The Most frequent test failures card ranks tests by failure count, and the Recent events table links each failure back to its source run.
You're looking for repeated failures in GitHub Actions jobs. The Most frequent test failures and Recent events sections include GitHub Actions jobs.
A job feels slow and you want to find the bottleneck. The Test duration trends chart and Top 5 slowest tests list rank by P95 duration so you can target the tests costing the most time.

Filter by timeframe (past 7, 30, 60, or 90 days, or month to date), repository, branch, suite, file, class, or test name. Filter state is stored in the URL, so you can share a link to a specific view. For a full breakdown of every section on the page, see Test results analytics by organization.

View results from the CLI

The depot tests command lists parsed test results from your terminal, so you can pull up a failure without leaving the shell. For GitHub Actions jobs, pass the GitHub Actions job ID with --gha:

# List results for a GitHub Actions job
depot tests <github-job-id> --gha

# Show only failures
depot tests <github-job-id> --gha --status failed

--gha restricts the lookup to GitHub Actions results, since Depot otherwise tries the ID as both GitHub Actions and Depot CI results. The --job and --workflow flags are Depot CI only and don't apply here.
--status (passed, failed, errored, or skipped, repeatable), --suite, --test, --class, and --file narrow the output.
--output sets the format: a table in a terminal, JSON when piped, or JSON always with --output json.
--token and --org handle auth: the command uses your depot login session unless you pass --token, and --org is required when you belong to more than one organization.

For the full list of flags and usage, see depot tests in the CLI reference.

Pricing

The Developer and Startup plans each include 1,000,000 passing test results per month at no charge. After that, it's $0.000001 per passing test, or $1 per 1 million tests. Failed, errored, and skipped tests are free.

Test-results usage is billed monthly along with the rest of your Depot usage. Your organization's usage page breaks down reports, total tests, and billable tests by day and by repository. If you're on the Business plan or an annual contract, contact us for custom volume pricing. See Pricing for full plan details.