Allure Report Storage

The Allure Report Storage service allows to publish Allure Report reports to and seamlessly integrates with history feature, making possible to see previous reports in a single click.

• Learn more about Allure Report at https://allurereport.org
• 📚 Documentation – discover official documentation for Allure Report
• ❓ Questions and Support – get help from the team and community
• 📢 Official annoucements – be in touch with the latest updates
• 💬 General Discussion – engage in casual conversations, share insights and ideas with the community

Usage

The service integrates seamlessly with Allure3, you just need to do these 4 simple steps:

1. Run the service using it inside Docker or as a Cloudflare worker
2. Generate access token using REST API
3. Add token to the Allure runtime config
4. Add publish flag to the options of reports which should be published

Installation

Docker

Continue reading here.

Cloudflare

Continue reading here.

Usage

Access token generation

Generate access token using the Storage API first (use access token previously passed to the service env variable):

curl -sS -X POST http://localhost:3000/api/token \
  -H "Authorization: Bearer storage_bootstrap_token"

If the service is behind TLS termination or a reverse proxy, set PUBLIC_URL before generating the token.

Then use it in the Allure Report runtime config:

import { defineConfig } from "allure";

export default defineConfig({
  name: "Allure Report",
  plugins: {
    awesome: {
      options: {
+       publish: true, // explicitly specify which reports should be published
      },
    },
  },
+  allureService: {
+    accessToken: "ars1...",
+  },
});

Public URL

PUBLIC_URL optionally overrides the origin embedded in newly generated POST /api/token access tokens. Set it when the request origin is not the public URL clients use, for example when TLS terminates at a reverse proxy:

PUBLIC_URL=https://reports.example.com

It does not change the server listening address or authentication. If it is unset, empty, or whitespace-only, the service uses the request origin instead.

The value must be an absolute HTTP(S) origin. A port and trailing slash are accepted; outer whitespace is trimmed and the value is normalized to its URL origin. Credentials, a path other than /, a query, and a fragment are not allowed.

Existing tokens retain the URL embedded when they were generated. Regenerate affected tokens after setting PUBLIC_URL, then replace them in client and CI configuration.

Main branch selection

If your main branch doesn't call main, you can specify a custom one to compare reports from another branches with:

curl -sS -X POST http://localhost:3000/api/projects/main-branch \
  -H "Authorization: Bearer storage_bootstrap_token" \
  -H "Content-Type: application/json" \
  -d '{ "repo": "repo_name", "main_branch": "main_branch_name"}'

Report retention

Automated report retention can delete old reports to reduce disk or storage costs. It is disabled by default and enabled only when at least one retention env var is set:

• REPORT_RETENTION_MAX_REPORTS_PER_BRANCH: keep newest completed reports per branch up to this positive integer limit, delete older ones.
• REPORT_RETENTION_MAX_REPORT_AGE_DAYS: delete reports older than this positive number of days. The newest completed report per branch is always preserved.

Both strategies can be enabled together. Retention does not change public history download limits or manual delete behavior.