skip to content

In Allure, what does `allure generate` produce from a results directory, and why does the generated `index.html` show nothing when you open it straight from the file system?

level: juniorimportance: must knowfreq 74%

answer

  1. two directories, not one
  2. the entry point is index.html
  3. the page asks for its own data
  4. a filesystem origin blocks those requests

basics

~20 s

allure generate turns a results directory into a static report directory, by default allure-report, whose entry point is index.html. That page loads its data over HTTP, so opened as a local file it renders empty; serve the directory instead.

solid answer

~40 s

`allure generate <results-dir>` reads the files a test run wrote and emits a static website into a report directory named by `-o` (aliases `--report-dir`, `--output`; default `allure-report`); the results directory is positional and defaults to `allure-results`. The output is an ordinary folder of files: `index.html` as the entry point, a JavaScript and CSS bundle, and the JSON data files the page requests at runtime. Because it requests them, opening `index.html` from a `file://` path gives you an empty shell -- the browser refuses those requests from a filesystem origin. So you view it either with `allure open <report-dir>`, which starts a local preview server, or by publishing the whole directory behind any static web server. In Allure 3 the same command runs whichever report plugins the `allurerc` config declares.

code

bash · 2 lines
bash
allure generate ./allure-results -o ./allure-report
allure open ./allure-report

go deeper

for a junior

Know the two directory names and which command turns one into the other, and say that the report is static files whose entry point is index.html.

for a middle

Explain that the page fetches its data at runtime, so a file-system open renders empty while the same directory served over HTTP works, and name the options that set the destination.

for a senior

Show how you would diagnose a blank report in CI: check the URL scheme, check that the whole directory was published, and check that generation actually read a non-empty results directory.

for a principal

Be ready to argue where report generation belongs in a delivery pipeline, treating the report as derived data that can be regenerated from retained results rather than as the artefact of record.

## Two directories, and why they are confused The Allure flow has exactly two directories, and mixing them up is the commonest beginner mistake. - The **results directory** -- `allure-results` by default -- is what the *test run* writes. It holds one `-result.json` per executed test plus `-container.json` and `-attachment` files. It is machine input; nobody reads it. - The **report directory** -- `allure-report` by default -- is what the *generator* writes. It is a static website. `allure generate` is the step between them. Its results directories are positional (you may pass more than one, and they are merged into a single report), and the destination is `-o`, with the aliases `--report-dir` and `--output`. If a results directory does not exist or is not a directory, the CLI logs a warning and skips it, which is why a mis-typed path yields a report that generates fine and contains nothing. ## What the generated site actually is The output is a plain folder of files with **`index.html` as its entry point**, next to a JavaScript and CSS bundle and a set of JSON data files that the page loads while it runs. There is nothing server-side about it: no application server, no database, no runtime configuration, no build step at view time. That is the whole point of the format -- anything that can serve files over HTTP can serve an Allure report, and the report behaves identically wherever it is served from. The practical consequence is that **you must publish the whole directory**, not just the HTML file. Copying `index.html` alone to a wiki or a chat message produces a page that cannot find anything it needs. ## Why the file-system open shows an empty page The report is a browser application that asks for its data at runtime rather than having it baked into the markup. When the page is loaded over `http://`, those requests are ordinary same-origin requests and succeed. When the page is loaded from a `file://` path, the browser treats the document as having an opaque origin and blocks the requests, so the application starts, finds no data, and renders a blank or skeleton page. Nothing is corrupt; the report simply never received its own content. The three cures, in the order you will normally reach for them: | Way to view it | What it needs | What you get | |---|---|---| | `allure open <report-dir>` | the Allure CLI on the machine | a local preview server plus a browser window | | any static web server | somewhere to publish the directory | a URL colleagues can open | | single-file mode | `--single-file` at generation time | one HTML file that opens from disk | ## The two majors Both live Allure majors have a `generate` command and both default the destination to `allure-report`, so the shape of the answer is version-stable. The option sets are not: - **Allure 2 (2.47)** takes `-c/--clean` and `--single-file` on `generate`, and its four commands are `generate`, `serve`, `open` and `plugin`. - **Allure 3 (3.16.1)** has no `--clean` on `generate`, binds `-c` to `--config` instead, and drives generation from an `allurerc` config file that names the report plugins to run. Single-file output there is a plugin option rather than a `generate` flag. ## Diagnosing a blank or empty report 1. **Is it being served over HTTP?** Look at the address bar. A `file://` URL is the answer most of the time. 2. **Did the whole directory get published?** Missing bundle or data files look exactly like the `file://` symptom. 3. **Did `generate` actually read any results?** A warning about a missing directory, or a results directory the run never wrote to, gives you a valid but empty report. 4. **Do you need to send it to somebody?** Then generate the single-file variant instead of emailing a folder. ## Where this sits in a pipeline In CI the generation step is just a command between the test step and whatever publishes static files. The report is produced *after* the run from files the run left behind, so it can be regenerated at any time from the same results, and generating twice from the same results produces the same site. That property is what makes the report safe to treat as a build artefact: it is derived data, and the results directory is the thing worth keeping.

  • A colleague copies the report directory onto a shared drive, opens index.html and sees an empty page. What do you tell them?
    That a shared drive serves files over the file system, not over HTTP, so the report cannot load its data. Either publish the directory on a static web server and send a URL, or regenerate it in single-file mode, which inlines everything into one HTML document that does open from disk.
  • You point `allure generate` at the wrong path and the command succeeds. What did it do?
    It warns that the path does not exist or is not a directory, skips it, and still generates a report -- an empty one. A successful exit is not evidence that any results were read, so a CI step should check that the results directory it expected is non-empty rather than trusting the exit code.

saying these in an interview costs you the question

  • Thinks the results directory is already the report
  • Says double-clicking index.html shows the whole report
  • Cannot separate allure-results from allure-report
  • Believes the report needs an application server or database
  • Publishes index.html alone and expects it to work