In Allure 3, how is the generated report directory laid out when the `allurerc` config declares one report plugin versus several, and why does that matter to whatever serves the site?

seniorshould knowfreq 36%

answer

the config key becomes a path segment
one subdirectory gets flattened away
two or more keep theirs
the root turns into a landing page
adding a plugin moves the report's URL

basics

~20 s

Each report plugin writes into a subdirectory of the output named by its config key. A lone subdirectory is flattened into the output root; with two or more, they stay and a generated landing page becomes the root index.html.

solid answer

~50 s

In Allure 3 allurerc's plugins is a map whose key is the plugin id -- validated as a single safe path segment, because it becomes a directory name under output (default allure-report). Every file a plugin writes lands under <output>/<id>/. At the end of the run, if the output holds exactly one subdirectory, its contents are moved up into the root and the empty directory removed, so the report is served straight from the site root. If two or more report plugins produced directories, they stay where they are and a landing page linking each one is written as the root index.html. The consequence for hosting is that adding or removing a report plugin changes the URL of the report itself -- a link that used to open the report now opens a landing page, and the report has gained a path segment.

In Allure 3 `allurerc`'s `plugins` is a map whose key is the plugin id -- validated as a single safe path segment, because it becomes a directory name under `output` (default `allure-report`). Every file a plugin writes lands under `<output>/<id>/`. At the end of the run, if the output holds exactly one subdirectory, its contents are moved up into the root and the empty directory removed, so the report is served straight from the site root. If two or more report plugins produced directories, they stay where they are and a landing page linking each one is written as the root `index.html`. The consequence for hosting is that **adding or removing a report plugin changes the URL of the report itself** -- a link that used to open the report now opens a landing page, and the report has gained a path segment.

code

javascript · 9 lines

javascript

import { defineConfig } from "allure";

export default defineConfig({
  output: "./allure-report",
  plugins: {
    awesome: { options: {} },
    classic: { options: {} },
  },
});

go deeper

for a junior

Know that Allure 3 generation is driven by the plugins named in an allurerc config, and that the output directory defaults to allure-report.

for a middle

Explain that each plugin's files go under a subdirectory named by its config key, and that a lone subdirectory is flattened up into the output root at the end of generation.

for a senior

Show that you would catch the URL change: a config edit moves the report between the root and a plugin path, breaking saved links without failing the build.

for a principal

Treat report URLs as an interface the organisation depends on, and set a convention for plugin ids and published paths before several teams start linking into the same site.

The plugin id is a directory name

Allure 3 does not generate one fixed report. It runs whatever report plugins the allurerc config declares, and plugins is a map rather than a list:

the key is the plugin id;
the value carries the plugin's options, and may carry an import naming the package, so the same plugin can appear twice under two ids with different options.

That id is not cosmetic. It is validated as a single safe path segment -- no empty string, no dot segments, no path separators -- because everything the plugin writes goes under <output>/<id>/. output is a top-level config key and defaults to allure-report.

The flattening rule

If the layout stopped there, the single-plugin case -- by far the commonest -- would leave nothing at the site root and every deployment would need a redirect. So the generator has one more step at the end of the run:

It lists the output directory.
If exactly one subdirectory is present, it moves that subdirectory's contents up into the output root and removes the empty directory. A couple of integration files that belong at the root are left where they are.
If more than one is present, they are left alone and a landing page summarising the reports is written as the output root's index.html, linking each one under its plugin id.

So both shapes give you a root index.html, which is why a single-plugin report published to a static host works with no configuration at all -- but they give you a different root page and different deep-link paths.

`allurerc` plugins	Output root	Where the report lives
one report plugin	the report's own `index.html`	the site root
two or more	a generated landing page	`<pluginId>/` under the root
plugins that write no files	unchanged	not represented as a directory

Plugins that write nothing to disk -- a terminal log plugin, for instance -- create no directory and do not affect the count.

Why this is a hosting problem, not a cosmetic one

The layout is decided by config, so a change nobody thinks of as a deployment change moves the report:

Adding a second report plugin to try a different presentation moves the original report from / to /<pluginId>/. Every bookmark, dashboard link, badge and pipeline-comment URL now lands on a landing page instead of on the report, and anything that deep-linked into the report is broken by the extra path segment.
Removing one of two plugins does the reverse: the surviving report is flattened up to the root and the landing page disappears, breaking /<pluginId>/ links that people had saved.
Renaming a plugin id in the config renames the directory, and therefore the URL.

None of this fails at generation time. The generation is green; only the links are wrong, and they are wrong for readers rather than for the pipeline, so the report goes on being published and quietly stops being reachable at the address people use.

How to keep it stable

Decide the shape deliberately. Either commit to one report plugin and publish from the root, or accept the landing page and publish the plugin ids as stable public paths.
Pin the ids. Treat a plugin id in allurerc as a published URL segment -- name it once and do not rename it for tidiness.
Link the report you mean. If your team's link points at the site root and you may add a second report later, expect the root to become an index page and say so in the link text, or link the plugin path from the start.
Check the output shape in the publish step. A step that verifies the entry point exists where the deployment expects it turns a silent link break into a build failure.

Contrast with the previous major

Allure 2 has no plugin-directory layer here: generate writes the report at the root of the directory named by -o, and there is nothing to flatten. Teams upgrading from a pipeline that published allure-report/ verbatim keep working on Allure 3 while their config names a single report plugin, and discover the subdirectory rule the day somebody adds a second one.

## The plugin id is a directory name Allure 3 does not generate one fixed report. It runs whatever report plugins the `allurerc` config declares, and `plugins` is a map rather than a list: - the **key** is the plugin id; - the value carries the plugin's `options`, and may carry an `import` naming the package, so the same plugin can appear twice under two ids with different options. That id is not cosmetic. It is validated as a single safe path segment -- no empty string, no dot segments, no path separators -- because everything the plugin writes goes under `<output>/<id>/`. `output` is a top-level config key and defaults to `allure-report`. ## The flattening rule If the layout stopped there, the single-plugin case -- by far the commonest -- would leave nothing at the site root and every deployment would need a redirect. So the generator has one more step at the end of the run: 1. It lists the output directory. 2. **If exactly one subdirectory is present**, it moves that subdirectory's contents up into the output root and removes the empty directory. A couple of integration files that belong at the root are left where they are. 3. **If more than one is present**, they are left alone and a landing page summarising the reports is written as the output root's `index.html`, linking each one under its plugin id. So both shapes give you a root `index.html`, which is why a single-plugin report published to a static host works with no configuration at all -- but they give you a *different* root page and different deep-link paths. | `allurerc` plugins | Output root | Where the report lives | |---|---|---| | one report plugin | the report's own `index.html` | the site root | | two or more | a generated landing page | `<pluginId>/` under the root | | plugins that write no files | unchanged | not represented as a directory | Plugins that write nothing to disk -- a terminal log plugin, for instance -- create no directory and do not affect the count. ## Why this is a hosting problem, not a cosmetic one The layout is decided by config, so a change nobody thinks of as a deployment change moves the report: - **Adding a second report plugin** to try a different presentation moves the original report from `/` to `/<pluginId>/`. Every bookmark, dashboard link, badge and pipeline-comment URL now lands on a landing page instead of on the report, and anything that deep-linked into the report is broken by the extra path segment. - **Removing one of two plugins** does the reverse: the surviving report is flattened up to the root and the landing page disappears, breaking `/<pluginId>/` links that people had saved. - **Renaming a plugin id** in the config renames the directory, and therefore the URL. None of this fails at generation time. The generation is green; only the links are wrong, and they are wrong for readers rather than for the pipeline, so the report goes on being published and quietly stops being reachable at the address people use. ## How to keep it stable 1. **Decide the shape deliberately.** Either commit to one report plugin and publish from the root, or accept the landing page and publish the plugin ids as stable public paths. 2. **Pin the ids.** Treat a plugin id in `allurerc` as a published URL segment -- name it once and do not rename it for tidiness. 3. **Link the report you mean.** If your team's link points at the site root and you may add a second report later, expect the root to become an index page and say so in the link text, or link the plugin path from the start. 4. **Check the output shape in the publish step.** A step that verifies the entry point exists where the deployment expects it turns a silent link break into a build failure. ## Contrast with the previous major Allure 2 has no plugin-directory layer here: `generate` writes the report at the root of the directory named by `-o`, and there is nothing to flatten. Teams upgrading from a pipeline that published `allure-report/` verbatim keep working on Allure 3 while their config names a single report plugin, and discover the subdirectory rule the day somebody adds a second one.

Your team's report link points at the site root. Someone adds a second report plugin and the link now opens an index page. What is the minimal fix?
Point the link at the plugin id path, which is where that report now lives, and treat the id as a public URL segment from then on. Reverting to a single report plugin also works and restores the root, but choose one shape deliberately rather than letting the config decide the URL by accident.
Can the same report plugin appear twice in one config?
Yes. The map key is the id and the descriptor can name the package to import, so you can declare the same plugin under two ids with different options -- a hosted variant and a single-file variant, for example. Each id gets its own directory, and two directories mean the root becomes a landing page.

saying these in an interview costs you the question

Assumes the report is always at the output root
Treats plugin ids as private names, not URL segments
Renames a plugin id without expecting link breakage
Thinks a second plugin overwrites the first's output
Believes Allure 2 also uses per-plugin subdirectories

In Allure 3, how is the generated report directory laid out when the `allurerc` config declares one report plugin versus several, and why does that matter to whatever serves the site?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The plugin id is a directory name

The flattening rule

Why this is a hosting problem, not a cosmetic one

How to keep it stable

Contrast with the previous major

▾common follow-ups2 questions

▾red flags5 flags

The plugin id is a directory name

The flattening rule

Why this is a hosting problem, not a cosmetic one

How to keep it stable

Contrast with the previous major

answer

go deeper