skip to content

In an Allure results directory, what does a `-globals.json` file carry that a `-result.json` file cannot?

level: middleimportance: nice to knowfreq 34%

answer

  1. some evidence belongs to no case
  2. run-level, not test-level
  3. attachments plus errors
  4. same pointer, extra timestamp
  5. found by its own glob

basics

~10 s

Run-level payloads. A -globals.json file holds attachments that belong to the whole run rather than to any one test or fixture, alongside run-level errors, so there is no case to hang them off.

solid answer

~40 s

A `-result.json` file describes one test, so every payload it names belongs to that test. Some evidence does not: a broker log covering the whole session, a container's stdout, a capture of the machine the run happened on. `-globals.json` is where those go. Its shape is a `Globals` object with two lists — `attachments`, holding `GlobalAttachment` entries, and `errors`, holding failures that belong to the run rather than to a case. A `GlobalAttachment` extends the ordinary `Attachment`, so it carries the same `name`, `source`, `type` and `size` and points at a payload file in the same directory; what it adds is a `timestamp` recording when during the run it was added. The suffix constant is `-globals.json` and the glob is `*-globals.json`.

code

json · 11 lines
json
{
  "errors": [],
  "attachments": [
    {
      "timestamp": 1724662802000,
      "name": "Broker container log",
      "type": "text/plain",
      "source": "7c41a9b2-0e3d-4a18-8b77-2c5d6e7f8a90-attachment.txt"
    }
  ]
}

go deeper

for a junior

Know that some evidence belongs to a whole run rather than to one test, and that Allure gives it a home of its own instead of forcing it onto an arbitrary case.

for a middle

Explain the file's shape — a Globals object with attachments and errors — and that GlobalAttachment reuses the ordinary pointer fields while adding a timestamp for ordering.

for a senior

Be ready to say what breaks in a pipeline: a collection step globbing only *-result.json drops run-level payloads entirely, and the files those entries name must travel with the JSON like any other payload.

for a principal

Own the placement rule for a suite: decide by ownership, not by size, and be able to argue why parking case-specific evidence at run level makes the top of every report noisier for everyone.

## The gap `-globals.json` fills Every payload described so far hangs off something: a test, or a fixture that ran around one. That works as long as the evidence is *about* a case. Plenty of it is not: - The log of a message broker, database or emulator that the whole run shared. - A capture of the host the run happened on — package versions, container image digests, the output of a start-up script. - A recording or trace that spans the session rather than any single case. - The output of a step that ran before any test existed, or after the last one finished. Attaching those to an arbitrary test is the wrong answer twice over: it is a lie about ownership, and it hides the payload behind whichever case a reader happens to open. `-globals.json` exists so the format has somewhere honest to put them. ## What the file contains The file holds a single `Globals` object with two lists: 1. **`attachments`** — a list of `GlobalAttachment` entries, the run-level payloads. 2. **`errors`** — failures that belong to the run rather than to any case, such as something going wrong in the harness itself outside a test. A `GlobalAttachment` **extends** the ordinary `Attachment`, which is the key structural fact. It is not a different kind of pointer: | field | inherited from `Attachment`? | what it holds | |---|---|---| | `name` | yes | the label the report displays | | `source` | yes | the payload file's name in the results directory | | `type` | yes | the media type of the bytes | | `size` | yes | the payload's length once a reader has measured it | | `timestamp` | **no — added here** | when during the run the payload was added | Because the four inherited fields are unchanged, the payload files themselves are ordinary payload files: same `-attachment` naming, same directory, found by the same glob. Only the pointer lives somewhere different. ## Why the `timestamp` is there An ordinary attachment inherits a position in time for free: it belongs to a test, and that test has a start and a stop. A run-level payload has no such anchor. Without a timestamp it is a file with a label and no place in the run's story, and you cannot tell whether the broker log was captured before the suite started or after it collapsed. The `timestamp` restores the ordering the containing test would otherwise have supplied. ## Where the file sits, and how tools find it `-globals.json` is a **suffix**, not a fixed file name — the same pattern the format uses throughout. A run may produce several of these files, and a tool collects them with the glob `*-globals.json`, exactly as it collects `*-result.json`. Both majors of the report generator read them, so it is a version-stable part of the results contract rather than a feature of one generation. The practical consequences are the same as for any other pointer in this format: - The payload files these entries name must travel with the JSON, or the run-level evidence dangles just as a per-test attachment would. - A collection step that globs only `*-result.json` will pick up the tests and silently drop every run-level payload, because it never matched the file that names them. - Nothing forces a run to produce one. A suite that attaches nothing at run level simply has no such file, and its absence is not an error. ## When to reach for it The test is ownership, not size or importance. Ask: *if this payload explains a failure, which case does it explain?* If the honest answer is "all of them" or "none of them — it is about the run", it belongs at run level. If the answer names a case, it belongs on that case, where a reader looking at that failure will actually find it. A useful side effect is that run-level payloads survive being read out of context. A shared-service log attached to the fourteenth case in a suite is discoverable only by someone who already suspects that case. The same log at run level is one click from the top of the report, which is where somebody looking at a wave of unrelated failures actually starts. The cost is the mirror image: a run-level payload is not filtered away when a reader narrows to one test, so anything genuinely case-specific parked at run level is noise for everybody. Keep the distinction honest and each level stays readable.

  • A run-level payload is described in `-globals.json`. Where do its bytes live?
    In the results directory, in an ordinary payload file, exactly as a per-test attachment's would. `GlobalAttachment` extends `Attachment` and reuses `source` unchanged, so the same `-attachment` naming and the same `*-attachment*` glob apply. Only the pointer moved; the payload file did not become a different kind of artefact.
  • Why does a run-level attachment need a `timestamp` when a per-test one does not?
    A per-test attachment inherits its place in time from the test that owns it, which has a start and a stop. A run-level payload has no owning case, so without a timestamp there is nothing to say whether it was captured before the suite began, mid-run, or after everything had already failed.

saying these in an interview costs you the question

  • Thinks run-level payloads go on the first test
  • Says -globals.json is a fixed single filename
  • Assumes global payloads are stored inside the JSON
  • Confuses run-level payloads with fixture attachments