An Allure 2 report is regenerated on every CI build, yet its trend chart always shows a single point and each test case page shows only the current run. What is missing, and where does Allure 2 get trend data from?
answer
- no database behind the report
- trends are an input, not a memory
- a folder has to arrive with the results
- history/history.json under the results directory
basics
~20 sThe previous report's history directory is missing. Allure 2 keeps no database: it builds trends only from a history folder already present in the results directory it reads, so you copy that folder in from the last report before generating.
solid answer
~40 sAllure 2's generator has no server and no database, and no command on its CLI takes a history option. Trends come from a `history/` directory that is already present **in the results directory** the generator reads: it looks for `<results>/history/history.json` and the trend series beside it, and if they are not there it produces a report with a single data point. A generated report writes its own updated `history/` folder, so the carry step is to copy `allure-report/history` into `allure-results/history` before running `allure generate`. In a fresh CI workspace nothing has been copied in, so every build looks like the first run of the suite.
go deeper
Be ready to say that Allure 2 stores nothing between runs, and that a trend appears only because the previous report's history folder was copied into the new run's results before generating.
Explain the read path precisely: the generator resolves history/history.json inside the results directory it was given, and skips it in silence when the file is absent. Name the trend series files that sit beside it.
Show how you would prove the carry actually happened in a real pipeline -- inspect the generated report's own history folder and count its entries -- and treat a single-point trend as a missing input rather than a rendering bug.
Own the fact that this trend is a chain of hand-carried files with no server enforcing it. Decide what your organisation guarantees about that chain, and how a team finds out their trend has silently restarted.
## The generator has no memory Allure 2 is a static report generator. `allure generate` reads one or more **results directories** -- folders full of `*-result.json`, `*-container.json` and attachment files written while the suite ran -- and writes a **report directory** (default `allure-report`) that is a self-contained static site. Between those two directories there is no database, no service, and no state that outlives the process. The command line reflects that: **no Allure 2 command takes a history option at all.** There is nothing to switch on. So a trend cannot come out of the generator's memory, because it has none. It has to arrive as an **input**, alongside the results. ## Where the generator looks Every trend feature in Allure 2 is a plugin, and every one of them reads from the same place: a subdirectory named `history/` **inside the results directory it was handed**. | file, under `<results>/history/` | what it feeds | |---|---| | `history.json` | the run-by-run history block on an individual test case's page | | `history-trend.json` | the run-over-run trend chart | | `duration-trend.json` | the duration trend | | `categories-trend.json` | the categories trend | That read is guarded by a plain file-existence check. If `<results>/history/history.json` is not there, the plugin returns without contributing anything -- **no warning, no error, no non-zero exit**. A build whose carry step silently did nothing and the genuine first run of a brand-new suite look identical to the generator, and both render a trend with a single point. ## Where the data comes from The same generation pass that consumes `history/` also **produces** one. As the report is written, the history plugins serialise their updated series into `<report>/history/`, so a finished `allure-report` already contains exactly the folder the next build needs: ```bash cp -R ./allure-report/history ./allure-results/history allure generate ./allure-results -o ./allure-report ``` That is the whole mechanism. A trend exists because build N+1 was handed build N's output as part of its input. Nothing is renamed or transformed on the way: the filenames the generator writes under `history/` on the report side are exactly the filenames it looks for under `history/` on the results side, so a recursive directory copy is the entire operation. ## Why the direction and the order matter The copy has to go **into the results directory**, and it has to happen **before** generation. Two mistakes are common, and both produce the same silent single-point trend: 1. **Copying into the report directory.** The report directory is output, not input. Generation rebuilds it from the results, and the generator never reads it as a source, so a `history/` folder placed there is either overwritten or simply ignored. 2. **Copying after generation.** The trend data is computed and serialised during the generation pass. Dropping a history folder next to a report that has already been written changes no chart, because the chart's data file was produced minutes earlier. ## What this looks like in a pipeline A CI job usually begins in a workspace holding nothing but a checkout. Nothing from the previous build is present unless the pipeline deliberately put it there. That is why "our trend is empty" is so often mis-diagnosed as a rendering fault, a browser problem or a version mismatch. The report is correct; it was simply handed no history to draw. The question to ask of a suspect pipeline is not *is the chart broken*, it is **did anything write `history/` into the results directory before `allure generate` ran?** Two smaller consequences follow from the same design: - **The folder travels as a unit.** The trend series files sit beside `history.json` in the same directory, so carrying one file forward and not the others gives you a case-level history with no chart, or a chart with no case-level history. - **The carried file does not grow forever.** The generator prepends the current run to each series and keeps a bounded window, discarding the oldest entries as it goes, so the file a pipeline carries has a stable size rather than one that grows for the life of the project. ## The one-line summary An Allure 2 trend is not remembered, it is **carried**. The previous report's `history/` directory is an input to the next generation; it has to sit inside the results directory; and it has to be there before the generator runs. Miss any one of those three and the report is still produced, still valid, and still shows one point.
- When the carried history file is absent, does the generator fail, warn, or carry on?It carries on. The read is guarded by a plain existence check with no failure branch, so a missing `<results>/history/history.json` is indistinguishable from a genuine first run. Nothing turns red, and the only symptom is a trend with one point -- which is exactly why this fault survives in pipelines for months without anyone noticing.
- Which files sit in that carried directory besides `history.json`?Trend series files, including `history-trend.json`, `duration-trend.json` and `categories-trend.json`, each written by its own trend plugin into the same `history/` folder of the generated report. They are read from the same folder on the results side, which is why the carry step copies the whole directory rather than a single file.
saying these in an interview costs you the question
- Claims Allure 2 stores run history in a database
- Thinks a command-line flag switches trends on
- Copies the history folder into the report directory
- Assumes an empty trend means the chart is broken