Open-Source Testing · EnricoMi

publish-unit-test-result-action

A GitHub Action that parses test result files (XML, JSON, TRX formats) and publishes summaries as check annotations, pull request comments, and job summaries. Runs on Linux, macOS, and Windows with support for Docker and non-Docker variants.

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/EnricoMi/publish-unit-test-result-action

745

GitHub stars

229

Forks

Python

Primary language

Apache-2.0

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	EnricoMi/publish-unit-test-result-action
Owner	EnricoMi
Primary language	Python
License	Apache-2.0 — OSI-approved
Stars	745
Forks	229
Open issues	63
Latest release	v2.24.0 (2026-06-15)
Last updated	2026-07-01
Source	https://github.com/EnricoMi/publish-unit-test-result-action

What publish-unit-test-result-action is

Python-based GitHub Action that ingests JUnit/NUnit/XUnit XML, JSON (Dart/Mocha), and TRX (MSTest/VS) test outputs, then writes results to GitHub Checks API, pull request comments, and workflow job summaries. Provides platform-specific distribution variants (linux/docker, macos, windows, windows/bash).

Quickstart

Get the publish-unit-test-result-action source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/EnricoMi/publish-unit-test-result-action.git2cd publish-unit-test-result-action3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Multi-language CI/CD test reporting

Centralize test results from heterogeneous test suites (Java Maven, .NET MSTest, JavaScript Jest/Mocha, Python pytest, Scala sbt, Dart) into a single GitHub pull request and commit check without custom glue code.

Pull request quality gates

Automatically annotate changed files with test failures and summary comments on PRs, enabling developers to see test impact before merge without leaving GitHub.

Self-hosted runner environments

Deploy to non-Docker self-hosted Linux runners or Windows runners where Docker is unavailable; includes bash-only variant for constrained Windows environments.

Implementation considerations

Action always runs even if test step fails (use `if: (!cancelled())` in workflow); does not fail by default on test failure—configure `action_fail` and `fail_on` options explicitly.
Requires GitHub workflow permissions: `checks: write` and `pull-requests: write` for public repos; add `contents: read` and `issues: read` for private repos.
When multiple instances run in one workflow, each must set unique `check_name` to avoid result overwrites; otherwise second run replaces first.
Test result file paths can be relative (default) or absolute; absolute paths require separate configuration documented in README.
Platform variant selection matters: Docker (linux, default), native (macos, windows), or bash-only (windows/bash); incorrect choice may fail silently.

When to avoid it — and what to weigh

Real-time test streaming needed — Action processes completed test result files; does not support live streaming or incremental test reporting during test execution.
Complex test analytics and trending — Focused on per-run reporting; no built-in dashboard, historical trend analysis, or performance metrics aggregation across workflows.
Custom binary or proprietary test formats — Limited to declared formats (JUnit XML, NUnit XML, XUnit XML, TRX, JSON); custom proprietary formats require upstream transformation.
Offline or non-GitHub CI/CD systems — Tightly coupled to GitHub (Checks API, pull requests, job summaries); not portable to GitLab, Bitbucket, or other platforms.

License & commercial use

Apache License 2.0 (Apache-2.0). Permissive OSI-approved license allowing commercial use, modification, and distribution with attribution and liability disclaimer. No restrictions on proprietary derivative works or closed-source deployments.

Apache-2.0 is a well-established permissive license compatible with commercial use. No licensing fees, vendor lock-in, or compliance restrictions for internal or SaaS deployments. Ensure license notice is retained in any distributed derivative; consult legal counsel if bundling with proprietary code.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Active
Documentation	Strong
License clarity	Clear
Deployment complexity	Low
DEV.co fit	Strong
Assessment confidence	High

Security considerations

Action runs with GitHub token scoped to `checks: write` and `pull-requests: write` (or broader in private repos). Test result files are parsed as input and reported to GitHub—verify test result files are from trusted sources (not user-supplied untrusted input). No cryptographic operations, secret handling, or network calls beyond GitHub API. Standard GitHub Actions security practices apply (token rotation, OIDC token use).

Alternatives to consider

GitHub Actions: dorny/test-reporter

Similar test result parsing and GitHub Checks publishing; distinct implementation choice. Evaluate if feature parity or ecosystem preference guides selection.

Third-party test reporting SaaS (e.g., TestRail, Allure, PagerDuty Rundeck)

Provides centralized test analytics, dashboards, and trend analysis across projects/teams. Trade-off: additional vendor dependency, costs, and external data routing.

In-house GitHub Actions workflow using GitHub CLI (`gh`) and REST API

Custom shell/Python script to parse test files and POST to GitHub Checks API. Higher implementation burden but full control over filtering, aggregation, and failure logic.

Software development agency

Build on publish-unit-test-result-action with DEV.co software developers

Implement publish-unit-test-result-action to automatically surface test outcomes in pull requests and commit checks. Works with Maven, pytest, Jest, MSTest, and more—no custom glue code required.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

test-reporter tparse unit-testing-tips

Related on DEV.co

Explore the category and the services that help you build with it.

Open-Source Testing DevOps & CI/CD API Development Web Application Development Talk to DEV.co

publish-unit-test-result-action FAQ

Does this action fail the workflow if tests fail?

No by default. The action does not fail the workflow on test failure; it only reports results. Configure `action_fail: true` to fail the action if tests fail. The upstream test executor (Maven, pytest, jest) should be configured to fail on test failure.

Can I use this on pull requests from forks or Dependabot branches?

Yes, but requires additional setup. By default, GitHub Actions tokens in fork PRs lack write permissions. The README documents a separate section 'Support fork repositories and Dependabot branches' (not fully excerpted here); consult that for required GitHub App or token strategy.

What happens if I run this action multiple times in one workflow without unique check names?

The second run overwrites the first. Always set a unique `check_name` for each instance to avoid collision. Example: `check_name: 'Unit Tests'` and `check_name: 'Integration Tests'`.

Do I need Docker to use this action?

Not necessarily. Use `EnricoMi/publish-unit-test-result-action/macos@v2` for macOS, `windows@v2` for Windows, and `linux@v2` for self-hosted Linux without Docker. The default variant requires Docker.

Work with a software development agency

Need help beyond evaluating publish-unit-test-result-action? DEV.co is a software development agency offering software development services and web development for teams of every size. Our software developers and web developers build custom software, web applications, APIs, and open-source testing integrations — and maintain them long-term.

Standardize Test Reporting in GitHub

Implement publish-unit-test-result-action to automatically surface test outcomes in pull requests and commit checks. Works with Maven, pytest, Jest, MSTest, and more—no custom glue code required.

Talk to DEV.co Schedule a Consultation