Your pipeline copies the previous Allure 2 report's `history/` directory into each new run's results, yet the trend chart keeps restarting from one or two points. How do you diagnose that, and why can the lost trend not be rebuilt from the archived results directories?

## History is a chain, not an archive Each Allure 2 report's `history/` directory is derived from exactly two inputs: **the history directory carried into that run's results**, and **that run's own results**. The generator prepends the current run to each series and writes the combined series into the new report. That makes the sequence a chain of derivations: ``` report N-1/history -> results N/history -> generate -> report N/history ``` Nothing outside that chain holds the older points. There is no store the generator can go back to, and a results directory contains only the run that produced it. So the property that matters operationally is this: **the trend's depth is a function of the unbroken chain behind it, not of how many builds have run.** ## What breaks a chain The symptom -- a trend that keeps restarting from one or two points -- is almost always one of a small number of causes: - **A build that generated with nothing carried in.** Its report's `history/` contains only itself. Every subsequent build copies *that* folder forward, so the truncation propagates and the trend never recovers on its own. - **The copy running after generation rather than before.** The report is built with no history, and the folder copied afterwards is not read by anything. - **Copying into the report directory rather than the results directory.** The generator does not read its own output directory as a source. - **Carrying from a stale source.** If the copy always takes `history/` from the same pinned report rather than from the immediately preceding build of the same series, the trend is not restarting -- it is frozen, and each run appears as the second point. - **A different results directory than the one the generator was pointed at.** The carry lands in one folder and the generator reads another; both steps report success. Whether the previous report is *available* when the copy runs -- how a pipeline holds it between builds -- is a separate concern with its own answers. What belongs here is that the carry step must land the folder in the results directory the generator is about to read, before it reads it. ## Why nothing shouts The generator's history read is guarded by a file-existence check with no failure branch. A missing `<results>/history/history.json` is not an error and not a warning: the plugin contributes nothing and generation continues to a successful exit. That is a deliberate design -- the first run of any suite legitimately has no history -- but it means a broken carry step is **indistinguishable from a first run** in every signal the build emits. Pipelines lose their trend for months this way. ## Why archived results do not bring it back The instinct is to re-generate a report from the last several builds' archived results directories and get the trend back. It does not work, for a specific reason: `allure generate` accepts several results directories, but it **merges them into one report**. The current trend point is computed over everything the generator read in that pass, so six archived results directories produce **one** report with **one** new trend point covering all six runs' tests together, not six points in sequence. The only thing that could restore the earlier points is the `history/` file that existed at the time -- and if it had existed, the chain would not have broken. Re-generation recovers the per-run reports; it does not recover their ordering as a series. ## Diagnosing it Work from the artefacts, not from the chart: 1. **Open the generated report's `history/history.json`** and look at how many entries a stable, long-lived test case has. That is the real depth of the carried series, independent of anything the UI is doing. 2. **Check the results directory just before generation** and confirm `history/history.json` is present there. If your build log does not show that, add a step that does. 3. **Compare consecutive builds.** If build N's report has a deep history and build N+1's has one entry, the break is at N+1 and the cause is in that build's carry step, not in the data. 4. **Confirm the source.** Verify the copy took the previous build's report of the same series, not a fixed or default location that happens to hold an old one. ## What to change once you have found it The durable fix is to make the carry step's failure loud rather than silent: assert that `<results>/history/history.json` exists immediately before generation and fail the step if it does not, with an explicit exemption for the genuine first run of a series. That converts a permanently truncated trend into a red build on the day it breaks -- which is the only point at which the missing points are still recoverable, because the previous report still has them.