In an Allure 2 report, the tiles backed by `widgets/duration-trend.json` and `widgets/categories-trend.json` show points from earlier builds. How many points can such a file hold, and what happens to the oldest one when the next report is generated?

middleshould knowfreq 46%

answer

a count of builds, not a time range
current point prepended to the carried ones
the list is cut before it is written
twenty points, and the same list twice

basics

~20 s

An Allure 2 trend file keeps twenty points, newest first. Each generate prepends this run's point and cuts to twenty, writing that cut list to both the widget and history files, so a dropped point leaves the chain for good.

solid answer

~40 s

Each Allure 2 trend plugin reads the matching history/<name>.json out of the results directory, folds this run into a new point, puts that point at the head of the carried list, and truncates the whole thing to twenty entries. That one truncated list is written twice: to history/<name>.json, which the next run carries forward, and to widgets/<name>.json, which the tile draws. Because the cut happens before the write, an aged-out point disappears from the carry file as well as from the chart, and no later generate can bring it back. The window is also a count of generated reports, not a time range — twenty nightly builds is three weeks, twenty per-commit builds may be an afternoon — and a point carries only buildOrder, reportName, reportUrl and its data map.

Each Allure 2 trend plugin reads the matching `history/<name>.json` out of the results directory, folds this run into a new point, puts that point at the head of the carried list, and truncates the whole thing to twenty entries. That one truncated list is written twice: to `history/<name>.json`, which the next run carries forward, and to `widgets/<name>.json`, which the tile draws. Because the cut happens before the write, an aged-out point disappears from the carry file as well as from the chart, and no later generate can bring it back. The window is also a **count of generated reports**, not a time range — twenty nightly builds is three weeks, twenty per-commit builds may be an afternoon — and a point carries only `buildOrder`, `reportName`, `reportUrl` and its `data` map.

code

json · 14 lines

json

[
  {
    "buildOrder": 412,
    "reportName": "nightly",
    "reportUrl": "https://ci.example.com/nightly/412/allure",
    "data": { "duration": 612000 }
  },
  {
    "buildOrder": 411,
    "reportName": "nightly",
    "reportUrl": "https://ci.example.com/nightly/411/allure",
    "data": { "duration": 588000 }
  }
]

go deeper

for a junior

Know that a trend tile shows a limited number of past builds rather than everything the pipeline ever ran, and that the points sit newest first. Say the window is a count of reports, not a period of time.

for a middle

Walk the sequence: read the carried history file, build this run's point, prepend it, cut to the cap, then write the same list to both the history and the widget path. Explain why cutting before writing makes the drop permanent.

for a senior

Show that you plan for it — archiving each build's report or history file when a longer series matters, reading a suspiciously short trend as a broken carry rather than a small cap, and refusing to quote a slope off the chart as a rate per week.

for a principal

Own the retention design. Decide whether the report chain should be the system of record for trend data at all, given it is a fixed rolling window with no per-point timestamp, and where a queryable store has to take over instead.

How a trend point is built

Allure 2's trend tiles are the only panels on the overview that show anything from before the current run. Each one is produced by a trend plugin that does three things during a single generate:

Reads. Before aggregating, it looks for history/<name>.json inside the results directory — history/duration-trend.json, history/categories-trend.json and so on — and parses it into a list of points. If the file is not there, the list is empty and no error is raised.
Builds the current point. It folds this run's counted results into one new point, carrying buildOrder, reportName and reportUrl where the run's executor block supplied them, plus a data map of metric name to value.
Concatenates and truncates. The new point goes at the head of the carried list, and the combined list is cut to twenty entries. The order is newest first.

The truncation happens on write, into two places

That same truncated list is then written twice, under the same file name, into two directories of the generated report:

path	who reads it
`history/<name>.json`	the next run, if the pipeline carries the directory forward
`widgets/<name>.json`	the tile on this report's overview

This is the detail that decides how the window behaves. Because the cut happens before the write, the twenty-first point is not merely hidden from the chart — it is absent from the carry file too. The next run reads a list that is already missing it and prepends its own point to that. So the drop is destructive along the chain: no later generate can recover an aged-out point from the history it was handed, because it was never handed it.

The window is a count, not a time range

The cap counts points, and each point is one generated report. Nothing in the file records how far apart those reports were:

Twenty nightly builds span roughly three weeks.
Twenty per-commit builds on a busy repository may span an afternoon.
A pipeline that generates a report twice per build burns two slots per build.

A point carries buildOrder, reportName, reportUrl and its data map, and that is all. The chart is therefore an ordered series, not a timeline, and reading a slope off it as "per week" is an assumption the file does not support. If builds are irregular — nightly on weekdays, nothing at the weekend, a burst during a release — the visual spacing misleads even though every point in it is correct.

What that means in practice

Nothing on Allure 2's command line changes the cap. There is no history option there at all; the carry between runs is a directory copy the pipeline performs, and the cap is applied by the generator on the way out.
A longer series has to be your own archive. Keep each build's generated report, or at least its history/ files, somewhere you control. A year of build durations can be rebuilt by reading the head point out of each archived copy; it cannot be recovered from the current chain.
A short trend is not automatically a bug. A tile showing a handful of points on a pipeline that has run hundreds of times means the carry is not working. A tile showing a full twenty on a pipeline that has run thousands of times means the cap is doing exactly its job.
Widening the tile is not a setting you have overlooked. Treat the window as fixed and design the archive around it rather than hunting for a flag.

Reading the tile honestly

Two sentences cover it.

First, name the window: "this is the last twenty generated reports", never "this is the last month". The two coincide only by accident, and they stop coinciding the first time somebody changes how often the pipeline runs.

Second, name the direction. The newest point sits at the head of the array, so when you line a trend point up against another tile in the same report, take the head — everything behind it describes a different report, generated at a different time, possibly from a different results directory. That is also the reason a trend tile and a per-run tile on the same page can disagree without either of them being wrong.

## How a trend point is built Allure 2's trend tiles are the only panels on the overview that show anything from before the current run. Each one is produced by a trend plugin that does three things during a single generate: 1. **Reads.** Before aggregating, it looks for `history/<name>.json` inside the *results* directory — `history/duration-trend.json`, `history/categories-trend.json` and so on — and parses it into a list of points. If the file is not there, the list is empty and no error is raised. 2. **Builds the current point.** It folds this run's counted results into one new point, carrying `buildOrder`, `reportName` and `reportUrl` where the run's executor block supplied them, plus a `data` map of metric name to value. 3. **Concatenates and truncates.** The new point goes at the head of the carried list, and the combined list is cut to **twenty entries**. The order is newest first. ## The truncation happens on write, into two places That same truncated list is then written twice, under the same file name, into two directories of the generated report: | path | who reads it | |---|---| | `history/<name>.json` | the *next* run, if the pipeline carries the directory forward | | `widgets/<name>.json` | the tile on this report's overview | This is the detail that decides how the window behaves. Because the cut happens **before** the write, the twenty-first point is not merely hidden from the chart — it is absent from the carry file too. The next run reads a list that is already missing it and prepends its own point to that. So the drop is **destructive along the chain**: no later generate can recover an aged-out point from the history it was handed, because it was never handed it. ## The window is a count, not a time range The cap counts points, and each point is one generated report. Nothing in the file records how far apart those reports were: - Twenty nightly builds span roughly three weeks. - Twenty per-commit builds on a busy repository may span an afternoon. - A pipeline that generates a report twice per build burns two slots per build. A point carries `buildOrder`, `reportName`, `reportUrl` and its `data` map, and that is all. The chart is therefore an **ordered series, not a timeline**, and reading a slope off it as "per week" is an assumption the file does not support. If builds are irregular — nightly on weekdays, nothing at the weekend, a burst during a release — the visual spacing misleads even though every point in it is correct. ## What that means in practice - **Nothing on Allure 2's command line changes the cap.** There is no history option there at all; the carry between runs is a directory copy the pipeline performs, and the cap is applied by the generator on the way out. - **A longer series has to be your own archive.** Keep each build's generated report, or at least its `history/` files, somewhere you control. A year of build durations can be rebuilt by reading the head point out of each archived copy; it cannot be recovered from the current chain. - **A short trend is not automatically a bug.** A tile showing a handful of points on a pipeline that has run hundreds of times means the carry is not working. A tile showing a full twenty on a pipeline that has run thousands of times means the cap is doing exactly its job. - **Widening the tile is not a setting you have overlooked.** Treat the window as fixed and design the archive around it rather than hunting for a flag. ## Reading the tile honestly Two sentences cover it. First, name the window: *"this is the last twenty generated reports"*, never *"this is the last month"*. The two coincide only by accident, and they stop coinciding the first time somebody changes how often the pipeline runs. Second, name the direction. The newest point sits at the head of the array, so when you line a trend point up against another tile in the same report, take the head — everything behind it describes a different report, generated at a different time, possibly from a different results directory. That is also the reason a trend tile and a per-run tile on the same page can disagree without either of them being wrong.

You want a year of build durations from this tile. What do you actually have to keep?
Your own archive. The generator cuts the series and rewrites the carry file on every run, so the chain never holds more than the cap. Store each build's generated report — or at least its `history/duration-trend.json` — somewhere you control, and rebuild the long series from the head point of each copy.
The tile shows a full twenty points but the pipeline has run thousands of times. Is that a fault?
No, that is the cap working as designed. Each generate prepends one point and keeps the newest twenty, so a long-lived pipeline shows a rolling window. The chart describes the last twenty generated reports, not the pipeline's history.

saying these in an interview costs you the question

Thinks the trend covers a fixed period of time
Expects a command-line flag to widen the window
Believes dropped points survive in the carried history
Reads point spacing on the chart as regular intervals

In an Allure 2 report, the tiles backed by `widgets/duration-trend.json` and `widgets/categories-trend.json` show points from earlier builds. How many points can such a file hold, and what happens to the oldest one when the next report is generated?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

How a trend point is built

The truncation happens on write, into two places

The window is a count, not a time range

What that means in practice

Reading the tile honestly

▾common follow-ups2 questions

▾red flags4 flags

How a trend point is built

The truncation happens on write, into two places

The window is a count, not a time range

What that means in practice

Reading the tile honestly

answer

go deeper