allure-notifications: an Allure report that messages your team

The message is a collage plus counters plus links

The output is described as a collage PNG with a caption carrying statistics and links, and the structure of the message is given as a table of zones. The collage zone holds seven panels: current status, status dynamics, a pyramid, durations, success rate, duration dynamics and status transitions. The text zone holds the environment, a comment, the duration, and the passed, failed, broken and skipped counters. The links zone holds four links named report, dashboard, testops and build, and they come from a base.links section in the configuration. Splitting the message this way is a design decision about what a reader can act on. A chat notification that only says four hundred tests passed is a status update, while a collage with a success rate and a link to the failed run is something a person can act on without opening anything.

The GitHub Action, and the boundary it deliberately keeps

The Marketplace Action is the primary path, and the workflow step looks like this.

- uses: qa-guru/allure-notifications@v6
  with:
    config: notifications/config.json
    allure-folder: build/reports/allure-report/allureReport/awesome
    allure-results-folder: build/allure-results
    mode: live
  env:
    TELEGRAM_BOT_TOKEN: ${{ secrets.TELEGRAM_BOT_TOKEN }}
    TELEGRAM_CHAT_ID: ${{ vars.TELEGRAM_CHAT_ID }}
    TELEGRAM_TOPIC_ID: ${{ vars.TELEGRAM_TOPIC_ID }}

The credentials are passed as environment variables rather than through the config file, and the reason is stated: the Action never generates the report and never writes credentials to JSON. The pipeline is given as tests, then allure-results, then npx allure generate once, then the Action sends. So the report generation stays in your own pipeline, run once, and the Action only renders and delivers. The config file is a static artifact, the bot token comes from a secret, the chat id and topic id come from variables, and the mode is set to live for a real send rather than a dry run.

One tool, many messengers and almost every CI

The support matrix is wide, and it is organised as an omni-tool. On the messenger side the list covers Telegram, Slack, email, Mattermost, Discord, Loop, Rocket.Chat, Zoho Cliq and Microsoft Teams. On the CI side it covers local runs, GitHub Actions, GitLab CI, AWS CI, Azure DevOps, Jenkins, Bamboo, Bitbucket Pipelines, TeamCity, CircleCI and Buildkite, with the closing note that it works with any runner that can execute the CLI. On the language side the project works with any language that has Allure support, and the listed ones include Java, Kotlin, Groovy, JavaScript, TypeScript, Python, C#, PHP, Ruby, Go, Rust and Dart, with a link to the Allure frameworks list. On the notification locale side there are translations, with English, German and French named before the list is cut off, and the project keeps separate readme files in English, Russian and French. The practical meaning of this matrix is that the notification is a separate concern from the test framework, which is why it can sit at the end of any pipeline.

The monorepo, and the packages inside it

The project is a pnpm workspace with Node 26 or newer required, and the package manifest names the root package as a monorepo for Allure report to messenger notifications. The scripts section shows the shape of the work. The build runs the build in every workspace package, and there are scripts for tests, coverage, typecheck and publishing packages. The publish script filters on four package names, the notifications config package, the notifications core package, the notifications package itself and the notifications plugin package, and publishes them all with public access. There is a validate:action script that runs an action validator over action.yml, over a local action that asserts the collage, over several workflow examples and over the example workflow files, and then runs a script that validates the action contract. The top level also holds an action.yml, a sonar-project.properties, a c8.config.json, a MIGRATION.md and a CHANGELOG.md, and the repository includes examples for the GitHub Actions route and a local configuration example file.

Four ways to run it, and a config builder instead of a config file

The project offers runnable variants in four shapes, and they are listed in the repository's workflow documentation: the Marketplace Action, a native CLI, the Allure plugin, and a local Action. The build and config are separated on purpose, with a configuration builder that produces the config.json the Action then reads, so the same configuration can be committed and reused across pipelines. The documentation points at a complete workflow and a static config under the examples directory for GitHub Actions, and the panel gallery script in the manifest is a tool for choosing which panels go into the collage. The choice of build mode matters in CI, since the Action variant is a container that has to be pulled while the CLI variant runs the same logic directly on the runner.

The version history tells you where the project went

The releases and the package description together tell a migration story. The current release line is 6.x, with v6.3.2 on 2026-09-30, described as assistant fixes, and the manifest version matches at 6.3.2. The 6.0 line is the TypeScript monorepo with the CLI and the builder, and the package description records what came before. The 5.0 line was a Java jar, and it is archived on a branch named legacy/java-5.0.8, with the freeze and the release both at 5.0.8, and the description states plainly that there is no 5.1 line. The release list also shows a 4.11.1 on 2026-09-07 and a v5.1.2 on 2026-09-01, which means the old lines were still receiving releases while the new one was being written. The last push to the repository was on 2026-09-30, and the project is MIT licensed with a homepage at allure-notifications.qa.guru.

Editorial conclusion

allure-notifications fits a QA team that runs Allure in CI and wants the run summarised in the chat where the conversation already happens, rather than asking people to open a report link, and it fits teams that need the same notification from GitHub Actions, GitLab CI, Jenkins or a local machine. It does not fit a team that wants one tool for one chat platform, since the project supports Telegram, Slack, email, Mattermost, Discord, Loop, Rocket.Chat, Zoho Cliq and Microsoft Teams, and it does not fit anyone who wants the report generated for them, because the Action never generates the report and never writes credentials to JSON, so the report step stays in your pipeline. Before you wire it up, decide where the report generation belongs and keep the bot token in a secret rather than in the config file.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. qa-guru/allure-notifications on GitHub
4. README
5. Releases