An Allure report names the CI build that produced it and links back to that build. Which file in the results directory carries that, and what does each of its fields do?

middlemust knowfreq 52%

answer

one small JSON file in the results directory
eight fields, three of them URLs
a number field orders the builds
one field is an icon lookup key
buildUrl and reportUrl point at different sites

basics

~20 s

executor.json in the results directory carries it. Allure reads it as an ExecutorInfo holding name, type, url, buildOrder, buildName, buildUrl, reportName and reportUrl: which CI system ran the build, and where the build and the report can be opened.

solid answer

~40 s

The file is executor.json, read out of the results directory into an ExecutorInfo with eight fields: name, type, url, buildOrder, buildName, buildUrl, reportName and reportUrl. They are not all decoration. type is a lookup key that picks the executor icon, so a recognised token such as jenkins or github renders that system's mark and anything else gets a default. buildName is the text of the link and buildUrl its target, and Allure 2 renders no link at all when buildName is absent. buildOrder is a number used to order builds and to elect the latest executor when several results directories are consolidated. reportUrl is the base for links back into a published report, and reportName is Allure 2's fallback report title.

The file is `executor.json`, read out of the results directory into an `ExecutorInfo` with eight fields: `name`, `type`, `url`, `buildOrder`, `buildName`, `buildUrl`, `reportName` and `reportUrl`. They are not all decoration. `type` is a lookup key that picks the executor icon, so a recognised token such as `jenkins` or `github` renders that system's mark and anything else gets a default. `buildName` is the text of the link and `buildUrl` its target, and Allure 2 renders no link at all when `buildName` is absent. `buildOrder` is a number used to order builds and to elect the latest executor when several results directories are consolidated. `reportUrl` is the base for links back into a published report, and `reportName` is Allure 2's fallback report title.

code

json · 10 lines

json

{
  "name": "Jenkins",
  "type": "jenkins",
  "url": "https://ci.example.com",
  "buildOrder": 128,
  "buildName": "nightly-e2e #128",
  "buildUrl": "https://ci.example.com/job/nightly-e2e/128/",
  "reportName": "Nightly E2E",
  "reportUrl": "https://reports.example.com/nightly-e2e/128/"
}

go deeper

for a junior

Recall that the file is called executor.json, that it sits in the results directory, and that it is what makes a report say which build produced it.

for a middle

Walk through the eight fields and say which ones have behaviour: type picks the icon, buildName plus buildUrl make the link, buildOrder orders builds, reportUrl is the base for links home.

for a senior

Show you can debug the block: a report with no build link, a link that lands on the wrong site, or a build that never wins the latest-executor election all trace back to specific fields here.

for a principal

Decide what provenance every report in the organisation must carry, so that a report handed to someone in another team answers which build and where to look without a conversation.

A report that says a suite failed is worth much less than a report that says which build of which pipeline failed and where to open it. In Allure, that provenance comes from a single file in the results directory: executor.json.

How it is read

ExecutorPlugin looks for executor.json in each results directory it is given and deserialises it into an ExecutorInfo. Only that exact file name is recognised, and nothing produces it automatically: like the environment files, it is written into the results directory by whatever assembles the run's output. If it is absent the report is generated normally, simply without any build provenance.

Allure 3 reads the same file with the same eight fields, storing it as report metadata rather than as a Java object, so what follows is stable across both live majors unless noted.

The eight fields

field	what it holds
`name`	the display name of the CI system or executor
`type`	its kind, as a short lowercase token
`url`	the CI system's own address
`buildOrder`	a number, used to order builds
`buildName`	the display name of this build
`buildUrl`	the address of this build in the CI system
`reportName`	the display name for the generated report
`reportUrl`	the address the generated report is published at

Which fields actually do something

Treating all eight as decoration is the common mistake. Four of them drive behaviour:

type picks an icon. Allure 2's executors widget builds a CSS class from the value, so recognised tokens such as jenkins, teamcity, gitlab, github, bamboo, circleci, bitbucket and azure render that system's mark and anything else falls back to a default icon. It is a lookup key, not free text.
buildName and buildUrl make the clickable row. Allure 2's widget renders the link only when buildName is present; with buildName missing the row shows a translated placeholder instead. The URL additionally passes through a navigation sanitiser, and a URL that fails it degrades to plain text rather than becoming a link.
buildOrder orders and selects. When a report is generated from several results directories, Allure 2 asks for the latest executor by taking the maximum buildOrder, with missing values sorted first. It is also the number a trend point is labelled with.
reportUrl is what links home are built from. It is stamped onto trend points and is the base from which a per-result link back into a published report is constructed.

reportName has a narrower job: in Allure 2 the report's title is taken from the name given on the command line, and only when no such option was passed does it fall back to the latest executor's reportName, trimmed. With neither, the built-in default title is used. So executor.json can name a report without touching the invocation.

name and url are display fields on the Allure 2 widget side. Allure 3's report metadata combines them differently: it labels the executor with name and buildName where both exist, falls back through buildName, reportName, name, buildUrl, reportUrl and url in that order, and links that label to the first of buildUrl, reportUrl and url that is set.

The distinction people get wrong

buildUrl and reportUrl point at two different things, and swapping them produces a report whose "open the build" link lands on the report you are already reading:

url - the CI system as a whole.
buildUrl - one run of the job inside that system, where the logs and the console output live.
reportUrl - the published Allure report for that run, which is a static site somewhere else entirely.

What to check when the block seems ignored

The file is named executor.json exactly, and sits at the top of the results directory rather than in a subdirectory.
It parses as a JSON object. A malformed file is reported as a read error and the run continues without provenance.
buildOrder is a number, not a string. A quoted value will not order builds the way you expect.
If you are consolidating several directories, more than one executor.json may be present, and only the one with the highest buildOrder is treated as the latest.

A report that says a suite failed is worth much less than a report that says *which build* of *which pipeline* failed and where to open it. In Allure, that provenance comes from a single file in the results directory: `executor.json`. ## How it is read `ExecutorPlugin` looks for `executor.json` in each results directory it is given and deserialises it into an `ExecutorInfo`. Only that exact file name is recognised, and nothing produces it automatically: like the environment files, it is written into the results directory by whatever assembles the run's output. If it is absent the report is generated normally, simply without any build provenance. Allure 3 reads the same file with the same eight fields, storing it as report metadata rather than as a Java object, so what follows is stable across both live majors unless noted. ## The eight fields | field | what it holds | |---|---| | `name` | the display name of the CI system or executor | | `type` | its kind, as a short lowercase token | | `url` | the CI system's own address | | `buildOrder` | a number, used to order builds | | `buildName` | the display name of this build | | `buildUrl` | the address of this build in the CI system | | `reportName` | the display name for the generated report | | `reportUrl` | the address the generated report is published at | ## Which fields actually do something Treating all eight as decoration is the common mistake. Four of them drive behaviour: - **`type` picks an icon.** Allure 2's executors widget builds a CSS class from the value, so recognised tokens such as `jenkins`, `teamcity`, `gitlab`, `github`, `bamboo`, `circleci`, `bitbucket` and `azure` render that system's mark and anything else falls back to a default icon. It is a lookup key, not free text. - **`buildName` and `buildUrl` make the clickable row.** Allure 2's widget renders the link only when `buildName` is present; with `buildName` missing the row shows a translated placeholder instead. The URL additionally passes through a navigation sanitiser, and a URL that fails it degrades to plain text rather than becoming a link. - **`buildOrder` orders and selects.** When a report is generated from several results directories, Allure 2 asks for the *latest* executor by taking the maximum `buildOrder`, with missing values sorted first. It is also the number a trend point is labelled with. - **`reportUrl` is what links home are built from.** It is stamped onto trend points and is the base from which a per-result link back into a published report is constructed. `reportName` has a narrower job: in Allure 2 the report's title is taken from the name given on the command line, and only when no such option was passed does it fall back to the latest executor's `reportName`, trimmed. With neither, the built-in default title is used. So `executor.json` can name a report without touching the invocation. `name` and `url` are display fields on the Allure 2 widget side. Allure 3's report metadata combines them differently: it labels the executor with `name` and `buildName` where both exist, falls back through `buildName`, `reportName`, `name`, `buildUrl`, `reportUrl` and `url` in that order, and links that label to the first of `buildUrl`, `reportUrl` and `url` that is set. ## The distinction people get wrong `buildUrl` and `reportUrl` point at two different things, and swapping them produces a report whose "open the build" link lands on the report you are already reading: - `url` - the CI system as a whole. - `buildUrl` - one run of the job inside that system, where the logs and the console output live. - `reportUrl` - the published Allure report for that run, which is a static site somewhere else entirely. ## What to check when the block seems ignored 1. The file is named `executor.json` exactly, and sits at the top of the results directory rather than in a subdirectory. 2. It parses as a JSON object. A malformed file is reported as a read error and the run continues without provenance. 3. `buildOrder` is a number, not a string. A quoted value will not order builds the way you expect. 4. If you are consolidating several directories, more than one `executor.json` may be present, and only the one with the highest `buildOrder` is treated as the latest.

What does Allure 2's executors widget show when `executor.json` sets `name` and `type` but no `buildName`?
The row still appears with the executor's name and its icon, but the details column falls back to a translated placeholder instead of a link. A `buildUrl` on its own is not enough: the link is rendered only when `buildName` is present, and a URL that fails the widget's navigation sanitiser degrades to plain text rather than becoming a link.
Where does an Allure 2 report's title come from if `executor.json` carries a `reportName`?
The name given on the command line wins. With no such option, Allure 2 falls back to the latest executor's `reportName`, trimmed, and with neither it uses its built-in default title. So `executor.json` can name a report without anyone changing the generate invocation, which is useful when the same command generates several reports.

saying these in an interview costs you the question

Believes buildUrl and reportUrl are the same link
Thinks all eight fields are purely decorative labels
Expects Allure to invent executor.json from environment variables
Treats buildOrder as free text rather than a number
Assumes type is a display string rather than a lookup key

An Allure report names the CI build that produced it and links back to that build. Which file in the results directory carries that, and what does each of its fields do?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

How it is read

The eight fields

Which fields actually do something

The distinction people get wrong

What to check when the block seems ignored

▾common follow-ups2 questions

▾red flags5 flags

How it is read

The eight fields

Which fields actually do something

The distinction people get wrong

What to check when the block seems ignored

answer

go deeper