Allure 2's command line has no history option, so its trend depends on copying the previous report's `history/` directory into the next run's results. What does Allure 3 change about that, and does the carry-between-builds problem disappear?
answer
- convention becomes configuration
- a named path instead of a fixed folder
- historyPath, historyLimit, appendHistory
- naming a location does not preserve it
basics
~20 sAllure 3 makes history configuration explicit: historyPath, historyLimit and appendHistory are config keys and there is a history command, so the data no longer has to be smuggled in through the results directory. It still has to survive between builds.
solid answer
~40 sAllure 3 promotes history from a file-placement convention to configuration. Its `allurerc` config file carries top-level `historyPath`, `historyLimit` and `appendHistory` keys, and there is a dedicated `history` command, so you name where past runs are read from and how many are kept rather than hoping a folder lands where the generator happens to look. What does not change is the part that actually breaks pipelines: **the data still has to survive from one build to the next**. `historyPath` names a location, it does not create, populate or preserve one. Point Allure 3 at a path nothing has written to and you get the same report Allure 2 gives you with no carried folder -- valid, and showing one point.
go deeper
Know that the copy-a-folder mechanism is an Allure 2 answer, and that Allure 3 lets you configure a history path instead. Say which major you mean before describing either.
Name the Allure 3 keys and what each settles: where history is read from, how much is kept, and whether this run contributes. Then say plainly what none of them do.
Make the invariant explicit across both majors: the generator reads and extends history, it never stores it. Judge a proposed upgrade by whether it changes that, and be clear that it does not.
Weigh a major upgrade on more than this feature. Say what an explicit, configured history location buys a fleet of pipelines compared with a convention every team reimplements by hand.
## The Allure 2 position Allure 2's generator has no history option on its command line. The only route by which a previous run's numbers reach a new report is a `history/` directory sitting inside the results directory the generator is handed, put there by whatever runs the build. History is a *convention about file placement*, not a configured feature: nothing in the tool names it, bounds it, or knows where it came from. ## What Allure 3 adds Allure 3 promotes history to configuration. Its config file -- `allurerc.js`, `allurerc.mjs`, `allurerc.ts`, `allurerc.json`, `allurerc.yaml` and the other accepted extensions, resolved from the working directory -- carries top-level keys for it, and there is a dedicated `history` command beside `generate` and the report plugins. | key | what it settles | |---|---| | `historyPath` | where the generator reads past runs from, and writes them back to | | `historyLimit` | how many past entries are kept, rather than an unbounded file | | `appendHistory` | whether this run is added to that history at all | The practical difference is that the location becomes **explicit and separate from the results directory**. On Allure 2, the only way to tell the generator about history is to put a folder where it happens to look; on Allure 3, you name the path. That makes a few things straightforward that were awkward before: - history can live outside the results directory, so a results directory stays purely a run's own output; - a run can be told not to contribute to history, which matters for one-off or experimental generations; - retention has an owner in configuration rather than being whatever the generator's internal window happens to be. ## What does not change **The data still has to survive from one build to the next.** `historyPath` names a location; it does not create one, populate one, or preserve one across a workspace that is discarded at the end of a job. If nothing puts the previous run's history at that path before the generator runs, Allure 3 produces exactly what Allure 2 produces in the same situation: a valid report with a trend of one point. So the shape of the problem is unchanged and only the interface to it has moved: 1. Something must hold the history between builds. 2. Something must make it available to the generator before generation. 3. The generator reads it, extends it, and writes it back out. Allure 2 answers step 2 with a copy into a fixed relative path. Allure 3 answers it with a configured path. Neither answers step 1 -- that has never been the generator's job. ## Which one to describe in an interview State the version. The copy-into-results mechanism is an Allure 2 fact, and Allure 2 (2.47 at the time of writing) is still very widely deployed, so it is the answer most pipelines actually run on. Allure 3 (3.16.1) is the current major and its config keys are the modern answer. Presenting either as *the* answer without naming the major is the mistake worth avoiding.
- If you are on Allure 2 and cannot upgrade, what is the equivalent of `historyLimit`?There is no equivalent. Allure 2 offers no configuration for how much history is retained; the generator's own bounded window as it prepends each run is the only limit, and a pipeline that wants a different depth has no supported way to ask for one.
- Why is naming the major so important when answering a question about Allure history?Because the two majors give different answers and both are live. Allure 2 has no history option at all and depends on the copy into the results directory; Allure 3 has config keys and a command. Stating either as timeless is wrong for half the installed base.
saying these in an interview costs you the question
- Says configuring historyPath preserves history between builds
- States the copy mechanism as true of every Allure version
- Claims Allure 2 has a history flag somewhere
- Assumes Allure 3 stores past runs on its own