Install allure with Homebrew, apt, Nix, pacman, scoop

Project links

• Homepage
• Repository
• Upstream docs
• Package manager page

Commands and aliases

• allure

Project history

The Allure 2 repository presents the project as Allure Report and links the official site, documentation, Maven Central command-line artifact, release downloads, Qameta Software, Open Collective backers, and project discussions. The current documentation distinguishes Allure Report 2, described as the mature and broadly integrated line, from Allure Report 3, described as a newer version rebuilt for usability and compatibility.

The project grew around a separation familiar to test-tool package users: language/framework adapters produce Allure result files, then the standalone Allure command-line tool generates and serves a report. That split made it possible for one report renderer to serve Java, JavaScript, Python, Ruby, PHP, .NET, and other testing stacks.

Adoption history

Official documentation describes Allure as integrating with 30+ testing frameworks and CI/CD platforms such as Jenkins, GitHub Actions, and Azure DevOps. The README documents common package paths including release archives, Homebrew, Scoop, and Maven Central, which is why Allure shows up both as a Java ecosystem artifact and as a cross-platform CLI formula.

Allure 2 remains the widely used line according to the project's own llms.txt, while Allure 3 is maintained alongside it with migration guidance. That dual-track state matters to package maintainers because the formula named `allure` has historically meant the mature Allure 2 command-line distribution even as the upstream documentation increasingly teaches both versions.

How it is used

Typical usage is to run tests with an Allure adapter enabled, collect the generated result files, and invoke the `allure` CLI to generate or view an HTML report. The official docs emphasize report navigation, history and retries, attachments, visual analytics, framework setup, and CI integration.

In package-manager contexts, Allure is usually installed for its `allure` executable rather than for a library API. It is common in CI jobs as a post-test reporting step and in local QA workflows when developers want a richer view than raw JUnit XML, pytest output, or test-runner console logs.

Why package nerds care

Allure is a good example of a language-neutral CLI that sits beside many language-specific packages. The report generator has to be easy to install from Homebrew, Scoop, archives, Maven, and CI images because it is used after tests from many ecosystems have already run.

For formula maintainers, the interesting bit is not just the executable but the compatibility contract between adapter-generated result files and the report renderer. The Allure 2 versus Allure 3 split also makes version selection and migration guidance unusually visible for a test-reporting package.

Timeline

• Allure 2 era: The `allure2` repository became the official source for the mature Allure Report command-line/reporting tool.
• Allure 3 era: Official documentation added a newer Allure 3 line while continuing to support Allure 2.
• Current: Official docs describe Allure as open source, framework-agnostic, and integrated with 30+ frameworks across multiple programming languages.

Related projects

• Allure TestOps is Qameta's commercial DevOps-ready testing platform mentioned by the Allure Report README.
• Allure framework adapters for JUnit, pytest, Playwright, Cypress, TestNG, RSpec, NUnit, xUnit.net, and other tools produce data consumed by the report generator.
• CI integrations for Jenkins, GitHub Actions, Azure DevOps, TeamCity, Bamboo, JetBrains IDEs, and Visual Studio Code are documented as part of the Allure ecosystem.

Sources

• https://allurereport.org/docs.md
• https://allurereport.org/llms.txt
• https://raw.githubusercontent.com/allure-framework/allure2/master/README.md