Allure Report: Multi-Language Test Reporting for Development Teams

What Allure Report Provides for QA Teams

Allure Report addresses a common gap in test pipelines: test runners produce raw pass/fail data, but that output is hard to interpret across a large suite. The tool takes test execution results and renders them as HTML reports with graphs, timelines, and categorised failure views that make it easier to identify where a release broke and why.

The project description frames the goal as allowing everyone involved in development to extract the maximum information from everyday testing. This includes developers who want to see which test categories are failing, QA engineers who need to trace failures to specific steps, and managers who want a high-level view of test health.

The tool is actively maintained by Qameta Software, the company behind it. Enterprise use cases are addressed through a separate product, Allure TestOps, described in the README as a DevOps-ready testing platform. The open-source Allure Report covered here is the standalone report generator, not the managed platform.

How Allure Converts Test Output into Reports

Allure works in two stages. In the first stage, a test adapter in your test framework writes structured result files as tests run. In the second stage, the Allure command-line tool reads those result files and generates the HTML report. The README describes this as building unified reports for dozens of testing tools across eleven programming languages on several CI/CD systems.

The report output is static HTML. Once generated, it can be served from any static file host, attached to a CI build artifact, or opened directly in a browser. There is no running server required to view a generated report.

The repository structure reflects the two-stage design. The allure-commandline/ directory contains the CLI tool. The allure-generator/ directory contains the report generation logic. The allure-plugin-api/ directory exposes the extension interface for adding custom report sections. The plugins/ directory contains first-party plugins that ship with the distribution.

The build system uses Gradle (build.gradle.kts at the root). The project is Java-based, which accounts for its broad platform support: the CLI runs on any JVM-capable environment.

Installing Allure on macOS, Windows, and Linux

The README describes three installation paths. On macOS, Homebrew is the recommended approach.

$ brew install allure

On Windows, the Scoop package manager provides the install path. The README specifies downloading and installing Scoop first, then running the following in PowerShell.

scoop install allure

For Linux or for any platform without a package manager, the README points to the GitHub releases page. Each release has an assets section containing downloadable archives. The release page also shows tagged versions, which is useful for locking to a specific version in CI configurations.

The allurereport.org website hosts full documentation. A live demo at demo.allurereport.org lets you explore the report format and navigation without running any tests locally. The README explicitly links to it as a way to see the tool in action before installing.

The current release series is 2.x. The most recent release at the time of the last push was 2.46.1, published in September 2026. Releases 2.46.0 and 2.45.0 also shipped in August 2026, showing a cadence of multiple releases per month during this period.

Multi-Language Coverage and CI/CD Integration

The README states that Allure Report generates unified reports for dozens of testing tools across eleven programming languages on several CI/CD systems. The README does not enumerate the complete language or framework list in the available text, but the project's position as a widely used reporting layer for Java, Python, JavaScript, C#, Go, PHP, Ruby, and other ecosystems is its primary value proposition.

For Java teams, the existing ecosystem of JUnit and TestNG adapters is well established. For Python teams, pytest-allure plugins connect the test runner to the Allure result format. The framework adapter generates the result files in Allure's JSON format during test execution, and the CLI then reads those files to produce the report.

The allure-jira-commons/ directory in the repository indicates integration with Jira. The README does not detail this integration in the available text, but the directory name suggests it provides a path for linking test results to Jira issues, which matters for teams tracking defects in Jira alongside their test results.

The README mentions several CI/CD-related discussion channels in the GitHub organisation. The allure-generator/ component is responsible for the actual HTML output, meaning the report structure can be influenced through the plugin API without modifying the core generator.

Where Allure Report Is Not the Right Fit

Allure Report generates static HTML snapshots of a single test run or a defined set of runs. It does not maintain a persistent database of test results that you can query over time by default. Teams who need to track test failure trends across dozens of builds, compare failure rates week over week, or search historical test results will find the static report model limiting.

The plugin API extends the report, but writing a plugin requires understanding the allure-plugin-api/ module. The README does not document the plugin development process in the available text. Teams who need custom report sections and cannot find an existing plugin will need to invest time in reading the plugin API.

Allure is not a test runner. It does not run your tests. It reads the output your test runner produces. Teams who are evaluating test infrastructure and want a single tool that both runs and reports tests will need separate components: one for running and Allure for reporting.

The README does not describe access control for reports. If reports are served from a shared file host and contain sensitive test data or application details, that exposure is a concern to handle at the hosting layer rather than within Allure itself.

Allure Report vs. ReportPortal: Snapshots vs. Persistent History

ReportPortal is a self-hosted test reporting tool that maintains a persistent database of test results over time. The core difference from Allure is state: ReportPortal stores every test run in a database and provides dashboards that show trend data across builds. Allure generates a self-contained HTML report from a specific set of result files without retaining historical data on its own.

For a team running CI and wanting to look at a dashboard that shows whether a specific test has been flaky for the past two weeks, ReportPortal's persistent model is the appropriate tool. For a team that wants to open an HTML report of the last build and share it with a stakeholder via a link, Allure's static output is simpler and requires no running server.

Allure TestOps, the commercial product from Qameta Software, addresses the persistent dashboard use case within the Allure brand. The README describes it as a DevOps-ready testing platform for teams that need more than the open-source report generator provides. Teams who start with open-source Allure Report and later need persistent history have a migration path to Allure TestOps without switching toolchains.

Active Development, Licence, and Community

Allure Report is licensed under Apache-2.0. This is a permissive licence with no copy-left requirements for use in commercial products, and it includes a patent grant. The repository includes an AUTHORS file and acknowledges contributors on the README.

The last push to the repository was on 2026-09-23, five days before this writing. The recent release history shows version 2.46.1 in September 2026, 2.46.0 in August 2026, and 2.45.0 in August 2026. This pace indicates active maintenance with multiple releases per month. The project uses GitHub Actions for its build and code-quality workflows, as shown by the build and quality badges linked in the README.

The project maintains community channels through GitHub Discussions, divided into questions and support, official announcements, and general discussion. The README links to each channel directly, providing a clear path for getting help with integration questions.

The repository also contains an AGENTS.md file at the top level, which suggests there are documented guidelines for working with the codebase using AI coding tools.

Editorial conclusion

Allure Report is the right tool for teams who need rich, graphical HTML reports from their existing test suites without integrating a persistent server. It is the wrong choice for teams who need cross-run trend analysis stored in a database over weeks or months, or for teams whose testing setup falls outside the supported eleven languages. Before adopting it, verify that an Allure adapter exists for your test framework and version, since the README does not list individual framework compatibility tables; the live demo at demo.allurereport.org shows the report format before you invest in integration.

Frequently asked questions

Official sources

1. allure-framework/allure2 on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases