---
title: Configure Allure Report 3
description: Learn how to configure Allure Report 3 in your project
---

# Configure Allure Report 3

Allure Report 3 uses a single configuration file to manage all your report settings. You can create this file in either dynamic (JavaScript) or static (JSON/YAML) format. Dynamic configs support executable code, imports, and conditional logic, while static configs provide a simpler format with fixed values.

You can load configuration values from environment variables and override them via CLI command options, giving you flexibility in how you manage settings across different environments and workflows.

Advanced Allure 3 features are implemented as a system of plugins. You can configure all plugins in the same configuration file.

## What This Document Covers

- Configuration file structure and syntax
- All primary configuration options
- Adding plugins and configuring multiple reports types
- Advanced features like history tracking and known issues
- CLI commands and overrides

## 1. Configuration File Basics

### File Name and Location

Allure CLI looks for configuration files in the current working directory, in the following order (first file discovered gets parsed for configuration parameters):

- `allurerc.js`
- `allurerc.mjs`
- `allurerc.cjs`
- `allurerc.json`
- `allurerc.yaml `
- `allurerc.yml`

### File Format and Syntax

Allure 3 supports both dynamic configs (.mjs, .cjs, .js) and static configs (.json, .yml, .yaml).

Static configs have limited functionality (no imports, no reading from environment variables, no executable code) but work with a global install of Allure Report 3.

Dynamic config files are written in JavaScript. They require Allure 3 to be locally installed in your project and you can use the following in them:

- Environment variables
- Conditional logic
- Computed values
- Imported utilities

Details: Dynamic and Static Configuration File Examples

**allurerc.mjs:**
```javascript
import { defineConfig } from "allure";

export default defineConfig({
  name: "Allure Report",
  output: "./allure-report",
  historyPath: "./history.jsonl",
  qualityGate: {
    rules: [
      {
        maxFailures: 5,
        fastFail: true,
      },
    ],
  },
  plugins: {
    awesome: {
      options: {
        reportName: "HelloWorld",
        singleFile: false,
        reportLanguage: "en",
        open: false,
        charts: chartLayout,
        publish: true,
      },
    },
    allure2: {
      options: {
        reportName: "HelloWorld",
        singleFile: false,
        reportLanguage: "en",
      },
    },
    classic: {
      options: {
        reportName: "HelloWorld",
        singleFile: false,
        reportLanguage: "en",
      },
    },
    dashboard: {
      options: {
        singleFile: false,
        reportName: "HelloWorld-Dashboard",
        reportLanguage: "en",
        layout: defaultChartsConfig,
      },
    },
    csv: {
      options: {
        fileName: "allure-report.csv",
      },
    },
    log: {
      options: {
        groupBy: "none",
      },
    },
  },
  variables: {
    env_variable: "unknown",
  },
  environments: {
    foo: {
      variables: {
        env_variable: "foo",
        env_specific_variable: "foo",
      },
      matcher: ({ labels }) => labels.some(({ name, value }) => name === "env" && value === "foo"),
    },
    bar: {
      variables: {
        env_variable: "bar",
        env_specific_variable: "bar",
      },
      matcher: ({ labels }) => labels.some(({ name, value }) => name === "env" && value === "bar"),
    },
  },
});
```

**allurerc.json:**
```json
{
  "name": "Allure Report",
  "output": "./allure-report",
  "historyPath": "./history.jsonl",
  "qualityGate": {
    "rules": [
      {
        "maxFailures": 5,
        "fastFail": true
      }
    ]
  },
  "plugins": {
    "awesome": {
      "options": {
        "reportName": "HelloWorld",
        "singleFile": false,
        "reportLanguage": "en",
        "open": false,
        "publish": true
      }
    },
    "allure2": {
      "options": {
        "reportName": "HelloWorld",
        "singleFile": false,
        "reportLanguage": "en"
      }
    },
    "classic": {
      "options": {
        "reportName": "HelloWorld",
        "singleFile": false,
        "reportLanguage": "en"
      }
    },
    "awesome": {
      "options": {
        "reportName": "HelloWorld",
        "singleFile": false,
        "reportLanguage": "en",
        "open": false,
        "publish": true
      }
    },
    "dashboard": {
      "options": {
        "singleFile": false,
        "reportName": "HelloWorld-Dashboard",
        "reportLanguage": "en"
      }
    },
    "csv": {
      "options": {
        "fileName": "allure-report.csv"
      }
    },
    "log": {
      "options": {
        "groupBy": "none"
      }
    }
  },
  "variables": {
    "env_variable": "unknown"
  }
}
```

**allurerc.yaml:**
```yaml
name: Allure Report
output: ./allure-report
historyPath: ./history.jsonl
qualityGate:
  rules:
    - maxFailures: 5
      fastFail: true
plugins:
  allure2:
    options:
      reportName: HelloWorld
      singleFile: false
      reportLanguage: en
  classic:
    options:
      reportName: HelloWorld
      singleFile: false
      reportLanguage: en
  awesome:
    options:
      reportName: HelloWorld
      singleFile: false
      reportLanguage: en
      open: false
      publish: true
  dashboard:
    options:
      singleFile: false
      reportName: HelloWorld-Dashboard
      reportLanguage: en
  csv:
    options:
      fileName: allure-report.csv
  log:
    options:
      groupBy: none
variables:
  env_variable: unknown
```

### Dynamic Config File Capabilities and Prerequisites

#### For Node.js Projects

Add Allure as a development dependency to your project:

```bash
cd your-project
npm install -D allure
```

Then, wrap the configuration object with the `defineConfig` function:

```javascript
import { defineConfig } from "allure";

export default defineConfig({
  name: "My Allure Report",
  // ... configuration
});
```

#### For Other Types of Projects

You can use a global installation of Allure Report and just export the configuration object directly:

```js
export default {
  name: "My Allure Report",
  // ... configuration
};
```

This way, however, you won't get type hints.

You can get around that limitation by initializing a dummy Node.js project and installing Allure to it:

```bash
npm init --yes
npm install -D allure
```

Then, wrap the configuration object in the `defineConfig` function, just as you would for any Node.js project (see the section above).

#### Reading Environment Variables

Since dynamic config files are executable JavaScript, you can use:

```javascript
import { env } from "node:process";

export default {
  name: env.REPORT_NAME || "Default Report",
  output: env.CI ? "./ci-reports" : "./local-reports",
};
```

#### Importing Code

When using dymanic files you can offload some executable logic to other JavaScript files and then import it to your config from them.

You can also import code form other Node.js modules, including Allure 3 plugins.

### Default Top-Level Values Reference

| Option            | Default Value                                                                                                                              |
| :---------------- | :----------------------------------------------------------------------------------------------------------------------------------------- |
| `name`            | `"Allure Report"`                                                                                                                          |
| `output`          | `"./allure-report"`                                                                                                                        |
| `historyPath`     | `undefined`                                                                                                                                |
| `appendHistory`   | `true`                                                                                                                                     |
| `categories`      | `{ rules: [{ name: "Product errors", matchers: { statuses: ["failed"] } }, { name: "Test errors", matchers: { statuses: ["broken"] } }] }` |
| `variables`       | `{}`                                                                                                                                       |
| `environments`    | `{}`                                                                                                                                       |
| `defaultLabels`   | `{}`                                                                                                                                       |
| `knownIssuesPath` | `"./allure/known.json"`                                                                                                                    |
| `plugins`         | `{ awesome: { options: {} } }`                                                                                                             |
| `qualityGate`     | `{}`                                                                                                                                       |

## 2. Basic Configuration Options

### `name`

- **Type:** `string`
- **Default:** `"Allure Report"`
- **Description:** Display name for the report

```javascript
{
  name: "My Test Suite Report";
}
```

### `output`

- **Type:** `string`
- **Default:** `"./allure-report"`
- **Description:** Directory where the report will be generated

```javascript
{
  output: "./reports/allure";
}
```

## 3. History Options

### `historyPath`

- **Type:** `string`
- **Default:** `undefined`
- **Description:** Path to the history file that tracks test results across multiple runs
- **Format:** JSONL (JSON Lines) - each line contains data from one complete test run
- **Used for:**
  - Trend charts showing test behavior over time
  - Flaky test detection
  - Historical comparisons

```javascript
{
  historyPath: "./test-history/allure-history.jsonl";
}
```

### `appendHistory`

- **Type:** `boolean`
- **Default:** `true`
- **Description:** Controls history accumulation behavior

```javascript
{
  appendHistory: true;
}
```

**File Structure:** See [History File](/docs/how-it-works-history-files/#allure-report-3) document for details.

## 4. Categories

Define custom categories to group and classify failed and broken tests by status, error message, labels, and other criteria.

- **Type:** `{ rules: CategoryRule[] }`
- **Default:** Two built-in categories — Product errors ([failed](https://allurereport.org/docs/test-statuses/#failed)) and Test errors ([broken](https://allurereport.org/docs/test-statuses/#broken))
- **Purpose:** Create a "Categories" tab in reports that groups test results by error type. All test results are matched against custom rules first, in the order defined; unmatched failed/broken tests fall back to the default categories.

### Structure

```js
{
  categories: {
    rules: [
      {
        name: "Category title",           // Required
        id: "category-id",                // Optional, stable identifier that allows to change name
        matchers: { ... } | (data) => boolean | [...],  // Required, either object matcher or function matcher
        groupBy: ["severity", "owner"],   // Optional, determines organization levels
        groupByMessage: true,             // Optional, default: true
        groupEnvironments: true,          // Optional
        expand: false,                    // Optional, default: false
        hide: false,                      // Optional, default: false
      }
    ]
  }
}
```

You may also set `categories: false` to disable categories entirely (neither default categories nor custom rules will be applied).

### `matchers`

`matchers` is mandatory and has to be one of the following:

- **Object matcher** - a plain object with any combination of:

  - `statuses`: TestStatus[] - matches against [test status](/docs/test-statuses/), e.g. `["failed", "broken"]`.
  - `flaky`: boolean - determines whether the category should include [flaky](/docs/test-stability/#flaky-tests) tests. Requires [history](/docs/history-and-retries/#allure-report-3/) to work.
  - `labels`: { [labelName]: string | RegExp } - matches against [labels](/docs/how-it-works-test-result-file/#labels-array), as a regular expression. String input is converted into a RegExp object, so any regex metacharacters included in the string (like `.`, `*`, or `^`) will affect how the match behaves, e.g. `{ owner: /^alice/ }` will match all results where the `owner` label starts with `alice`.
  - `message`: (sub)string | RegExp - matches against the error message as a regular expression. Same as `labels`, any regex metacharacters in a provided string will affect the match.
  - `trace`: (sub)string | RegExp - matches against the stack trace as a regular expression. Same as `labels`, any regex metacharacters in a provided string will affect the match.
  - `transitions`: TestStatusTransition[] - matches against [transitions](/docs/test-stability/), e.g. `["new", "regressed"]`. Requires [history](/docs/history-and-retries/#allure-report-3/) to work.
  - `environments`: string[] - matches against [environments](/docs/environments/).

  Tests fitting all of these conditions will be included (AND logic applies here).

- **Function matcher** — `(data) => boolean`, where `data` contains `status`, `labels`, `message`, `trace`, `flaky`, `duration`, `transition`, `environment`.

  Function matcher [requires dynamic config](/docs/v3/configure/#dynamic-config-file-capabilites-and-prerequisites) to work, and just like with object matchers, you have to enable [history](/docs/history-and-retries/#allure-report-3/) to match against `flaky` and `transition`, and set [environments](/docs/environments/) to match against `environment`.

  When using function matchers, you can additionally filter by `duration` (e.g. `(data) => data.duration > 5000` ), implement complex logic gates across multiple conditions and use arbitrary JavaScript expressions to fine-tune your categories.

- **Array** — any mix of the above; the test matches if any matcher in the array matches (OR logic applies).

### `groupBy`

`groupBy` is optional, controls the nesting hierarchy inside the category tree. Each element is either a built-in string selector or a custom label object:

- Built-ins: `"flaky"`, `"owner"`, `"severity"`, `"transition"`, `"status"`, `"environment"`, `"layer"`
- Custom labels: `{ label: "myCustomLabel" }`

Example: `groupBy: ["severity", { label: "feature" }]` creates two levels of grouping — first by severity, then by feature — before showing individual test results.

### Example

**Categories via object matchers:**
```js
import { defineConfig } from "allure";

export default defineConfig({
  name: "Allure Report 3",
  output: "./allure-report",
  historyPath: "./history.jsonl", //required for flaky and status transitions detection
  categories: {
    rules: [
      {
        name: "Critical regressions by layer",
        id: "critical-regressions-by-layer",
        // this section determines what's included into the category
        matchers: {
          statuses: ["failed", "broken"],
          flaky: false,
          labels: { severity: "critical" },
          message: /expected|API/, // accepts regular expressions
          trace: /AssertionError|timeout|unexpected/, // accepts regular expressions
          transitions: ["regressed", "malfunctioned"],
          environments: ["staging", "production"],
        },

        // this section determines how the category is presented
        groupBy: ["layer", "owner", "status"],
        groupByMessage: true,
        groupEnvironments: true,
        expand: true,
        hide: false,
      },
    ],
  },
});
```

**Categories via function matchers:**
```js
import { defineConfig } from "allure";

export default defineConfig({
  name: "Allure Report 3",
  output: "./allure-report",
  historyPath: "./history.jsonl", //required for flaky and status transitions detection
  categories: {
    rules: [
      {
        name: "Critical regressions by layer",
        id: "critical-regressions-by-layer",
        // this section determines what's included into the category
        matchers: (data) =>
          (data.status === "failed" || data.status === "broken") &&
          !data.flaky &&
          data.labels.some((l) => l.name === "severity" && l.value === "critical") &&
          /expected|API/.test(data.message ?? "") &&
          /AssertionError|timeout|unexpected/.test(data.trace ?? "") &&
          (data.transition === "regressed" || data.transition === "malfunctioned") &&
          (data.environment === "staging" || data.environment === "production"),
        // this section determines how the category is presented
        groupBy: ["layer", "owner", "status"],
        groupByMessage: true,
        groupEnvironments: true,
        expand: true,
        hide: false,
      },
    ],
  },
});
```

**Documentation:** See [Categories Guide](/docs/categories/) for complete documentation.

## 5. Variables and Labels

### `variables`

Display custom key-value metadata at the top of the report.

- **Type:** `Record<string, string>`
- **Default:** `{}`
- **Where shown:** Top of report in awesome plugin
- **Purpose:** Display build/run metadata

#### Example

```javascript
{
  variables: {
    "App Version": "2.5.1",
    "Test Suite": "Regression v1.2",
    "Launch Date": "2025-10-20",
    "Build Number": "#1234",
    "Environment": "Staging"
  }
}
```

### `defaultLabels`

Apply default labels to tests.

- **Type:** `Record<string, string | string[]>`
- **Default:** `{}`
- **Behavior:** Non-overriding - only applies if test doesn't have that label
- **Purpose:** Provide fallback values for missing labels

#### Example

```javascript
{
  defaultLabels: {
    "severity": "normal",
    "owner": "unassigned",
    "layer": "unknown",
    "tags": ["needs-review"]
  }
}
```

#### How It Works

- Test with `severity: "critical"` → keeps `"critical"` (not overridden)
- Test without `severity` → gets `"normal"` from defaults
- Test without `tags` → gets `["needs-review"]`
- Test with `tags: ["smoke"]` → keeps `["smoke"]`

#### Label Values

**Single value:**

```javascript
"severity": "critical"
```

**Multiple values (array):**

```javascript
"tags": ["smoke", "regression", "api"]
```

## 6. Environments

Group and categorize test results by environment with custom matching logic.

- **Type:** `Record<string, EnvironmentDescriptor>`
- **Default:** `{}`
- **Purpose:** Create an "Environments" menu in reports and split test result tree into environment-based groups, which you can switch between using that menu.

### Structure

```javascript
{
  environments: {
    "environment-id": {                    // Key = ID: letters, digits, underscores, hyphens only
      name?: string,                       // Optional display name shown in the report; defaults to the ID
      matcher: ({ labels }) => boolean,    // Required
      variables?: Record<string, string>   // Optional
    }
  }
}
```

### Matcher Function

Receives test labels and returns `true` if the test belongs to this environment. Requires dynamic config to work.

**Payload structure:**

```javascript
{
  labels: [
    { name: "os", value: "Windows" },
    { name: "browser", value: "Chrome" },
    // ... more labels
  ];
}
```

**Note**: these labels should be set in the tests as there are no default values for environment labels.

### Example

**OS-based Environments:**
```javascript
{
  environments: {
    windows: {
      matcher: ({ labels }) =>
        labels.find(({ name, value }) => name === "os" && value === "Windows"),
      variables: {
        "OS": "Windows 11",
        "Architecture": "x64"
      }
    },
    macos: {
      matcher: ({ labels }) =>
        labels.find(({ name, value }) => name === "os" && value === "macOS"),
      variables: {
        "OS": "macOS Sonoma",
        "Architecture": "arm64"
      }
    },
    linux: {
      matcher: ({ labels }) =>
        labels.find(({ name, value }) => name === "os" && value === "Linux"),
      variables: {
        "OS": "Ubuntu 22.04",
        "Architecture": "x64"
      }
    }
  }
}
```

**Deployment Environments:**
```javascript
{
  environments: {
    staging: {
      matcher: ({ labels }) =>
        labels.find(l => l.name === "env" && l.value === "staging"),
      variables: {
        "Server": "staging.example.com",
        "Database": "staging-db"
      }
    },
    production: {
      matcher: ({ labels }) =>
        labels.find(l => l.name === "env" && l.value === "production"),
      variables: {
        "Server": "api.example.com",
        "Database": "prod-db-primary"
      }
    }
  }
}
```

### Environment Variables

Optional environment-specific variables override or extend global variables when viewing that environment.

**Merge behavior:**

1. Global `variables` shown in all views
2. Environment-specific `variables` override/add to globals when that environment is selected

### Use Cases

- Group tests by OS (Windows/macOS/Linux)
- Group by browser (Chrome/Firefox/Safari)
- Group by deployment environment (staging/production)
- Group by any custom label-based criteria

**Documentation:** See [Environments Guide](/docs/environments/) for complete documentation.

## 7. Known Issues Management

Track known test failures and link them to bug tracker tickets.

### `knownIssuesPath`

- **Type:** `string`
- **Default:** `"./allure/known.json"`
- **Description:** Path to JSON file containing known test failures

```javascript
{
  knownIssuesPath: "./config/known.json";
}
```

### File Structure

**File:** JSON array of known issue objects

```json
[
  {
    "historyId": "a3f5e9b2c1d4f8a7b6e5c4d3a2f1e0b9",
    "issues": [
      {
        "name": "JIRA-1234",
        "url": "https://jira.example.com/browse/JIRA-1234"
      }
    ],
    "comment": "Known flaky test due to database connection issues",
    "error": {
      "message": "Connection timeout"
    }
  }
]
```

### Fields

#### `historyId` (required)

- **Type:** `string`
- **Description:** The test's history ID (internal identifier unique to each test)
- **Format:** MD5 hash of test metadata (name, path, parameters)
- **How to get:** From raw test result files

#### `issues` (optional)

- **Type:** Array of link objects
- **Description:** Links to bug tracker tickets

```json
{
  "name": "JIRA-1234",
  "url": "https://jira.example.com/browse/JIRA-1234"
}
```

#### `comment` (optional)

- **Type:** `string`
- **Description:** Human-readable explanation of the known issue

#### `error` (optional)

- **Type:** Error object
- **Description:** Expected error pattern for this known issue

```json
{
  "message": "Connection timeout after 5000ms",
  "trace": "..."
}
```

### Creating Known Issues File

#### Automated (Recommended)

Use the CLI command to auto-generate from failed tests:

```bash
allure known-issue ./allure-results
```

**What it does:**

1. Finds all failed/broken tests
2. Extracts their `historyId`
3. Extracts any "issue" type links from test metadata
4. Creates `known.json` with standard comment

#### Manual

1. Find the `historyId` from raw test result files
2. Create or edit `known.json`
3. Add entry with desired fields

### How It Works

1. Test runs and has a `historyId`
2. Allure checks if this `historyId` exists in known issues
3. If match found:
   - Test marked as "known failure"
   - Issue links displayed
   - Comment shown
   - May affect Quality Gate evaluation

### Use Cases

- Track known flaky tests
- Link failures to bug tracker
- Provide context to team members
- Separate "new failures" from "known issues"
- Document expected failures

## 8. Plugin Configuration

### Plugin System Overview

Allure 3 uses a plugin-based architecture. Each plugin generates a specific type of report or provides additional functionality.

**Available Official Plugins:**

- `awesome` - Modern UI (recommended)
- `classic` - Classic/Allure 2-style UI
- `allure2` - Allure 2 compatibility
- `dashboard` - Dashboard view with charts
- `log` - Console log output
- `csv` - CSV export
- `slack` - Slack integration
- `testplan` - Test plan generation
- `jira` - Jira integration

You can find the official plugins code in the [Allure 3 repository](https://github.com/allure-framework/allure3/tree/main/packages).

### Basic Plugin Configuration

To enable a plugin in your project, install the plugin package:

```
npm add @allurereport/plugin-name
```

And add it to the `plugins` section of the config:

```javascript
{
  plugins: {
    "name": {
      options: {
        // plugin-specific options
      }
    }
  }
}
```

### Plugin Configuration Properties

#### `import` (optional)

Custom module path for the plugin

```javascript
{
  plugins: {
    "my-custom-id": {
      import: "@allurereport/plugin-awesome",
      options: {}
    }
  }
}
```

**Use case:** Running multiple instances of the same plugin with different configurations

#### `enabled` (optional)

Enable or disable the plugin

- **Type:** `boolean`
- **Default:** `true`

```javascript
{
  plugins: {
    awesome: {
      enabled: false,  // Disable this plugin
      options: {}
    }
  }
}
```

#### `options` (optional)

Plugin-specific configuration object

- **Type:** `Record<string, any>`
- **Default:** `{}`

```javascript
{
  plugins: {
    awesome: {
      options: {
        singleFile: true,
        reportLanguage: "en"
      }
    }
  }
}
```

### Multiple Reports

You can generate multiple reports by configuring multiple plugins:

```javascript
{
  plugins: {
    "awesome-framework": {
      import: "@allurereport/plugin-awesome",
      options: {
        reportName: "Framework View",
        groupBy: ["framework", "language"]
      }
    },
    "awesome-package": {
      import: "@allurereport/plugin-awesome",
      options: {
        reportName: "Package View",
        groupBy: ["package", "suite"]
      }
    },
    dashboard: {
      options: {
        reportName: "Dashboard"
      }
    }
  }
}
```

### Default Plugin

If no plugins are specified, Allure uses the `awesome` plugin by default:

```javascript
// These are equivalent:
export default { name: "Report" }

export default {
  name: "Report",
  plugins: {
    awesome: { options: {} }
  }
}
```

## 9. Plugin Options

### Awesome Plugin

**Recommended modern UI for Allure reports.**

#### Common Options

**`reportName`** (string)

- Overrides the top-level `name` for this report

**`singleFile`** (boolean, default: `false`)

- Generate report as a single standalone HTML file
- `true`: Single HTML file
- `false`: Multiple files

**`reportLanguage`** (default: `"en"`)

- Sets the UI language

**`groupBy`** (string[])

- Defines test result hierarchy organization
- Array of label names

**Common patterns:**

```javascript
// BDD-style hierarchy
groupBy: ["epic", "feature", "story"];

// Suite-based hierarchy
groupBy: ["parentSuite", "suite", "subSuite"];

// Package-based hierarchy
groupBy: ["package", "class", "method"];

// Module-based
groupBy: ["module", "parentSuite", "suite", "subSuite"];

// Custom hierarchy
groupBy: ["framework", "language", "package"];
```

**`filter`** (function) (Requires dynamic config)

- Determines which test results are included in the report.
- Receives a test result object; return a truthy value to include, falsy to exclude

**Common patterns:**

```javascript
// Include only tests with a specific label
filter: ({ labels }) =>
  labels.find(({ name, value }) => name === "framework" && value === "playwright");

// Exclude tests with a specific label
filter: ({ labels }) => !labels.find(({ name, value }) => name === "language" && value === "java");
```

**`charts`** (default: all charts included)

- Built-in charts configuration: charts configured here will be included in the Awesome report itself. Do not confuse with [Dashboard](#dashboard-plugin), which is a separate charts-only report type.
- For details on what the charts illustrate, please refer to the [full Charts documentation](/docs/visual-analytics/).
- To populate most charts properly, [history](#3-history-options) should be enabled.
- If `charts` is omitted, all available chart types are included with their default options, which you can review below:

Details: Full charts configuration example with all default options
```js
// Charts configuration with all chart types and all options set to default values
const allChartsDefaultValues = [
  {
    type: "currentStatus",
    title: "Current status",
    statuses: ["passed", "failed", "broken", "skipped", "unknown"], //included statuses
    metric: "passed", // status used to calculate the central percentage value
  },

  {
    type: "testResultSeverities",
    title: "Test results by severities",
    levels: ["blocker", "critical", "normal", "minor", "trivial"],  //included severities
    statuses: ["passed", "failed", "broken", "skipped", "unknown"], //included statuses
    includeUnset: true, //whether to show the “No severity“ section
  },

  {
    type: "statusDynamics",
    title: "Status dynamics",
    limit: 10, // number of shown runs, including the latest
    statuses: ["passed", "failed", "broken", "skipped", "unknown"], //included statuses
  },

  {
    type: "statusTransitions",
    title: "Status transitions",
    limit: 10, // number of shown runs, including the latest
  },

  {
    type: "testBaseGrowthDynamics",
    title: "Test base growth dynamics",
    statuses: ["passed", "failed", "broken", "skipped", "unknown"], //included statuses
    limit: 10, // number of shown runs, including the latest
  },  

  {
    type: "coverageDiff",
    title: "Coverage diff map",
  },

  {
    type: "successRateDistribution",
    title: "Success rate distribution",
  },

  {
    type: "problemsDistribution",
    title: "Problems distribution by environment",
    by: "environment", //can only be grouped by environments
  },

  {
    type: "stabilityDistribution",
    title: "Stability distribution by features",
    threshold: 90, // acceptable stability level in %
    skipStatuses: ["skipped", "unknown"], //skipped test statuses
    groupBy: "feature", //by what label to group the tests together
  },

  {
    type: "stabilityDistribution",
    title: "Stability distribution by epics",
    threshold: 90, // acceptable stability level in %
    skipStatuses: ["skipped", "unknown"], //skipped test statuses
    groupBy: "epic", //by what label to group the tests together
  },

  {
    type: "stabilityDistribution",
    title: "Stability distribution by stories",
    threshold: 90,  // acceptable stability level in %
    skipStatuses: ["skipped", "unknown"], //skipped test statuses
    groupBy: "story", //by what label to group the tests together
  },

  {
    type: "durations",
    title: "Durations histogram",
    groupBy: "none", //whether to group the tests by layer (other labels not supported)
  },

  {
    type: "durations",
    title: "Durations by layer histogram",
    groupBy: "layer", //whether to group the tests by layer (other labels not supported)
  },

  {
    type: "durationDynamics",
    title: "Durations dynamics",
    limit: 10, // number of shown runs, including the latest
  },

  {
    type: "statusAgePyramid",
    title: "Status age pyramid",
    limit: 10, // number of shown runs, including the latest
  },

  {
    type: "testingPyramid",
    title: "Testing pyramid",
    layers: ["unit", "integration", "e2e"], //layers of the pyramid, bottom to top
  },
        reportLanguage: "en",
        // charts configuration used within the Awesome report
```

#### Example Configuration

```javascript
{
  plugins: {
    awesome: {
      options: {
        singleFile: false,
        reportLanguage: "en",
        reportName: "My Awesome Report",
        groupBy: ["epic", "feature", "story"],
        filter: ({ labels }) => labels.find(({ name, value }) => name === "framework" && value === "playwright")
      }
    }
  }
}
```

#### Complete Options Reference

For all available options including experimental features, see:

- [AwesomePluginOptions source code](https://github.com/allure-framework/allure3/blob/main/packages/plugin-awesome/src/model.ts)

### Dashboard Plugin

**Dashboard view with charts and visualizations.**

#### Common Options

**`reportName`** (string)

- Dashboard title

**`singleFile`** (boolean, default: `false`)

- Generate as single file

**`reportLanguage`** (default: `"en"`)

- UI language

**`layout`** (array of widget configurations)

- Dashboard report charts configuration
- For details on what different charts illustrate, please refer to the [full Charts documentation](/docs/visual-analytics/).
- To populate most charts properly, [history](#3-history-options) should be enabled.
- If `layout` is omitted, all available chart types are included with their default options, which you can review below:

#### Example Configuration

Details: Full charts configuration example with all default options
```js
// Charts configuration with all chart types and all options set to default values
const allChartsDefaultValues = [
  {
    type: "currentStatus",
    title: "Current status",
    statuses: ["passed", "failed", "broken", "skipped", "unknown"], //included statuses
    metric: "passed", // status used to calculate the central percentage value
  },

  {
    type: "testResultSeverities",
    title: "Test results by severities",
    levels: ["blocker", "critical", "normal", "minor", "trivial"],  //included severities
    statuses: ["passed", "failed", "broken", "skipped", "unknown"], //included statuses
    includeUnset: true, //whether to show the “No severity“ section
  },

  {
    type: "statusDynamics",
    title: "Status dynamics",
    limit: 10, // number of shown runs, including the latest
    statuses: ["passed", "failed", "broken", "skipped", "unknown"], //included statuses
  },

  {
    type: "statusTransitions",
    title: "Status transitions",
    limit: 10, // number of shown runs, including the latest
  },

  {
    type: "testBaseGrowthDynamics",
    title: "Test base growth dynamics",
    statuses: ["passed", "failed", "broken", "skipped", "unknown"], //included statuses
    limit: 10, // number of shown runs, including the latest
  },  

  {
    type: "coverageDiff",
    title: "Coverage diff map",
  },

  {
    type: "successRateDistribution",
    title: "Success rate distribution",
  },

  {
    type: "problemsDistribution",
    title: "Problems distribution by environment",
    by: "environment", //can only be grouped by environments
  },

  {
    type: "stabilityDistribution",
    title: "Stability distribution by features",
    threshold: 90, // acceptable stability level in %
    skipStatuses: ["skipped", "unknown"], //skipped test statuses
    groupBy: "feature", //by what label to group the tests together
  },

  {
    type: "stabilityDistribution",
    title: "Stability distribution by epics",
    threshold: 90, // acceptable stability level in %
    skipStatuses: ["skipped", "unknown"], //skipped test statuses
    groupBy: "epic", //by what label to group the tests together
  },

  {
    type: "stabilityDistribution",
    title: "Stability distribution by stories",
    threshold: 90,  // acceptable stability level in %
    skipStatuses: ["skipped", "unknown"], //skipped test statuses
    groupBy: "story", //by what label to group the tests together
  },

  {
    type: "durations",
    title: "Durations histogram",
    groupBy: "none", //whether to group the tests by layer (other labels not supported)
  },

  {
    type: "durations",
    title: "Durations by layer histogram",
    groupBy: "layer", //whether to group the tests by layer (other labels not supported)
  },

  {
    type: "durationDynamics",
    title: "Durations dynamics",
    limit: 10, // number of shown runs, including the latest
  },

  {
    type: "statusAgePyramid",
    title: "Status age pyramid",
    limit: 10, // number of shown runs, including the latest
  },

  {
    type: "testingPyramid",
    title: "Testing pyramid",
    layers: ["unit", "integration", "e2e"], //layers of the pyramid, bottom to top
  },
        reportLanguage: "en",
        // charts configuration used in a Dashboard report
```

#### Complete Options Reference

For all available options, see:

- [DashboardPluginOptions source code](https://github.com/allure-framework/allure3/blob/main/packages/plugin-dashboard/src/model.ts)

**Note:** Dashboard generates a **standalone report** separate from awesome/classic plugins.

### Classic Plugin

**Classic Allure 2-style UI.**

#### Common Options

**`reportName`** (string)
**`reportLanguage`** (default: `"en"`)
**`singleFile`** (boolean)

#### Complete Options Reference

For all available options, see:

- [ClassicPluginOptions source code](https://github.com/allure-framework/allure3/blob/main/packages/plugin-classic/src/model.ts)

### Log Plugin

**Filtered console log view of test results.**

#### Example Configuration

```javascript
{
  plugins: {
    log: {
      options: {
        groupBy: "none",
        filter: ({ status }) => status === "failed" || status === "broken"
      }
    }
  }
}
```

#### Complete Options Reference

For all available options, see:

- [LogPluginOptions source code](https://github.com/allure-framework/allure3/blob/main/packages/plugin-log/src/model.ts)

## 10. Quality Gate

Controls the process exit code based on test result criteria, allowing test runs to pass or fail based on custom rules.

```javascript
{
  qualityGate: {
    rules: [
      {
        maxFailures: 5,
      },
    ];
  }
}
```

**Documentation:** See [Quality Gate Guide](/docs/quality-gate/) for complete documentation.

**Note:** This is a complex feature with its own dedicated documentation.

## CLI Configuration Overrides

Config options can be overridden from the command line:

```bash
allure generate \
  --config ./allurerc.mjs \
  --output ./custom-output \
  --name "Overridden Name" \
  --history-path ./custom-history.jsonl
```

**Overridable options:**

- `--name` / `--report-name`
- `--output` / `-o`
- `--history-path` / `-h`
- `--known-issues`
- Plugin-specific options (varies by command)

### Plugin-Specific Commands

Generate reports with specific plugins directly:

#### Awesome Report

```bash
allure awesome [options] <directory>
```

**Options:**

- `--single-file`
- `--logo`
- `--theme`
- `--report-language, --lang`
- `--group-by, -g`

#### Dashboard

```bash
allure dashboard [options] <directory>
```

#### Classic Report

```bash
allure classic [options] <directory>
```

#### CSV Export

```bash
allure csv [options] <directory>
```

#### Log Output

```bash
allure log [options] <directory>
```

### Utility Commands

#### Known Issues

```bash
allure known-issue [--output,-o] <directory>
```

Generates known issues file from failed tests.

#### History

```bash
allure history [--history-path,-h] [--report-name,--name] <directory>
```

Generates history to specified folder.

#### Test Plan

```bash
allure testplan [--output,-o] <directory>
```

Generates testplan.json.

### Help

Get detailed help for any command:

```bash
allure <command> --help
```

---

## Appendix: Type Definitions Reference

For reference, here are the main TypeScript interfaces that define the configuration structure:

### Config Interface

```typescript
interface Config {
  name?: string;
  output?: string;
  historyPath?: string;
  knownIssuesPath?: string;
  defaultLabels?: DefaultLabelsConfig;
  environments?: EnvironmentsConfig;
  variables?: ReportVariables;
  plugins?: Record<string, PluginDescriptor>;
  appendHistory?: boolean;
  qualityGate?: QualityGateConfig;
  allureService?: {
    url?: string;
    project?: string;
    accessToken?: string;
  };
}
```

### Supporting Types

```typescript
type DefaultLabelsConfig = Record<string, string | string[]>;

type ReportVariables = Record<string, string>;

type EnvironmentDescriptor = {
  name?: string;
  variables?: ReportVariables;
  matcher: (payload: { labels: TestLabel[] }) => boolean;
};

type EnvironmentsConfig = Record<string, EnvironmentDescriptor>;

interface PluginDescriptor {
  import?: string;
  enabled?: boolean;
  options?: Record<string, any>;
}

interface KnownTestFailure {
  historyId: string;
  issues?: TestLink[];
  comment?: string;
  error?: TestError;
}
```

## Additional Resources

- [Allure 3 GitHub Repository](https://github.com/allure-framework/allure3)
- [Charts and Visual analytics documentation](/docs/visual-analytics/)
- [Environments Feature](/docs/environments/)
- [Quality Gate Feature](/docs/quality-gate/)