An Allure 2 trend chart gains one point per build as expected, but no point carries a build number or links anywhere. What is missing, and can it be filled in later?
answer
- the series is fine, the labels are not
- a missing file, not a missing flag
- a point stores only three provenance fields
- written once, when the point is created
- executor.json, absent from the results directory
basics
~20 sThe results directory has no executor.json. A trend point stores only buildOrder, reportUrl and reportName as provenance, copied from the executor block when the point is created, so adding the file labels future points but never earlier ones.
solid answer
~40 sDistinguish this from a trend that restarts: the series here is fine, only its labels are missing. An Allure 2 trend point holds a statistic plus exactly three provenance fields - `buildOrder`, `reportUrl` and `reportName` - and those are copied onto the point from the latest `ExecutorInfo` at generation time. With no `executor.json` in the results directory, all three are written null and the point has nothing to display or link to. The important consequence is that this cannot be repaired retroactively: earlier points are carried forward from the previous report as data, so regenerating today gives today's point provenance and leaves every older point exactly as it was written. Adding `executor.json` fixes the series going forward, nothing more.
code
json · 8 lines[
{
"data": { "failed": 0, "broken": 1, "skipped": 2, "passed": 39, "unknown": 0, "total": 42 },
"buildOrder": null,
"reportUrl": null,
"reportName": null
}
]go deeper
Know that a trend point's build number and link come from a file in the results directory rather than from the test results themselves, and that the file is executor.json.
Explain that a point carries only buildOrder, reportUrl and reportName, and that they are copied from the executor block at the moment the report is generated.
Separate this symptom from a restarting trend before you touch anything, and be explicit that provenance is write-once per point: the fix is forward-only and old points stay anonymous.
Treat provenance as something every pipeline must emit by default, because it costs nothing on the day and is unrecoverable once a series of reports has been produced without it.
The symptom is specific and it is worth separating from the more common one. A trend that restarts from a single point every build is a history problem. A trend that **grows correctly** - one more point per build, in the right order - but whose points are all unlabelled and unclickable is a **provenance** problem, and provenance in Allure comes from one file: `executor.json`. ## What a trend point actually stores An Allure 2 trend point is a very small object. The history trend item holds a statistic - the counts of `failed`, `broken`, `skipped`, `passed` and `unknown`, with `total` derived - plus exactly three provenance fields: - `buildOrder` - `reportUrl` - `reportName` The duration, retry and category trends are built on the same base shape and carry the same three fields beside their own metric map. There is no field for a commit, a branch, a timestamp or an executor name: the entire vocabulary a trend point has for saying *which build this was* is those three values. ## Where the three fields come from When a report is generated, the current run's point is created from the results being read, and then the three fields are copied onto it from the **latest** `ExecutorInfo` - the executor block with the highest `buildOrder`, missing values sorting first. If there is no `executor.json` in the results directory, that copy never happens and the point is written with all three fields null. That is the whole mechanism. The chart is fine, the history carry is fine, the counts are right. The label is missing because nothing in the results directory ever said what the build was called. ## Why you cannot backfill it This is the part that costs an afternoon. The provenance is written **at the moment the point is created**, and from then on the point is data that is carried forward from one report into the next. Adding `executor.json` today gives today's point a build number and a link. Every point that was written before it stays null for as long as it stays in the series, because regenerating a report does not revisit the earlier points - it copies them forward as they are. Short of hand-editing the carried history data, the only way to recover the labels is to regenerate each old report from its own archived results directory with its own executor block present, which is rarely worth doing. ## The environment block is different, and the contrast is the diagnostic The environment block behaves in the opposite way, and knowing that tells you which problem you have: | | environment block | trend provenance | |---|---|---| | source | `environment.properties` / `environment.xml` in the current results directory | `executor.json` in the results directory, at generation time | | recomputed each run? | yes, entirely | no, past points are carried forward | | fixed by adding the file today? | yes, immediately | only for points written from now on | So a report that shows a full environment block and an anonymous trend is not a report that failed to read its results directory. It is one whose results directory has never carried an executor block. ## Diagnosing it 1. Confirm the trend is actually growing. If it restarts every build, this is not the problem you have. 2. Look for `executor.json` in the results directory the generator was pointed at - not in the workspace root, not in the published report. 3. If the file is there, check `buildOrder`. A block with no `buildOrder` still registers as an executor, so the report will show the executor while the trend point still has no number to label itself with. 4. If several results directories are being consolidated, remember that only the highest `buildOrder` wins. A block with no `buildOrder` loses to any block that has one. ## What to fix, once The fix is not clever: make the executor block part of whatever produces the results directory, so that every run has one, with a `buildOrder` that increases and a `reportUrl` that points at wherever the report will actually be published. Provenance is cheap to write on the day and impossible to reconstruct a month later, which is exactly the asymmetry that makes it worth doing before you need it.
- The `executor.json` is present but has no `buildOrder`. What still breaks?The point is written with a null `buildOrder`, so the chart has no number to label it with even though the report itself shows an executor. It also costs you the election when several results directories are consolidated: Allure 2 picks the latest executor by the largest `buildOrder` with missing values sorted first, so a block without one loses to any block that has one.
- The environment block is missing on older reports too. Does the same cannot-backfill rule apply there?No, and the contrast is the diagnostic. The environment block is recomputed from the current results directory every time a report is generated, so adding the file fixes the very next report completely. The trend is different because its earlier points are carried forward from the previous report, so a point written without provenance keeps that shape for as long as it stays in the series.
A trend point with no executor block is a photograph with nothing written on the back. The pictures still sit in the album in the right order, but a month later nobody can say which one was the release that broke, and there is no way to add the caption after the fact.
saying these in an interview costs you the question
- Expects regenerating today's report to backfill old trend points
- Blames the history carry for missing build labels
- Assumes Allure derives a build number from the result file names
- Thinks a trend point stores the whole executor block
- Confuses an unlabelled trend with a trend that restarts each build