Logs, Reports, output.xml, Rebot, and Result Post-Processing: Core Concepts and Mental Model

1. The problem: a console session is not durable release evidence

Chapter 13 made failure semantics truthful. Chapter 14 asks what happens after the process exits. A green or red console line is transient. CI, incident review, release approval, reruns, and trend systems need artifacts that preserve exactly which suite/test ran, its status, messages, timing, tags, and hierarchy.

Robot Framework solves this with a result model. The executor builds result state while tests run and serializes it to an output file. The default XML file is commonly named output.xml. Human-facing log.html and report.html are presentations generated from that result state. Rebot reads output files later and can filter, combine, merge, or regenerate presentations without executing the system under test again.

2. Read-only preflight before touching artifacts

python --version
python -m robot --version
python -m robot.rebot --version
# Inspect the intended results directory before a run.
# PowerShell: Get-ChildItem -Recurse results -ErrorAction SilentlyContinue
# Bash:       find results -maxdepth 3 -type f 2>/dev/null

Record the interpreter, Robot Framework/Rebot version, execution command, selected source path, output directory, and any files that already exist. The important question is provenance: if report.html already exists, which output.xml produced it? Never overwrite the only first-failure artifact merely to make a prettier report.

3. Mental model: execution result → evidence → presentations → post-processing

flowchart TD
A[.robot source + inputs] --> B[Robot executor]
B --> C[In-memory result model]
C --> D[output.xml / output.json]
C --> E[log.html]
C --> F[report.html]
C --> G[xUnit XML optional]
D --> H[Rebot]
H --> I[Filtered/combined/merged result model]
I --> J[new log/report]
I --> K[new output file optional]
I --> L[xUnit optional]
M[Artifact retention policy] --> D
M --> E
M --> F
M --> K
N[Privacy/access policy] --> M

The executor is the only box that calls test keywords and changes the system under automation. Rebot is downstream: it reads result artifacts and transforms result state. That distinction matters during an incident. A report regenerated with a different title is not a new test execution. A merged result can change the final presentation of a rerun, but it must retain enough provenance to explain which original result was replaced.

4. Define the owners before modifying result data

5. What output.xml proves—and what it does not

In Robot Framework 7.4.2 the authoritative XSD is schema version 5. The root <robot> element can carry generator, generated, rpa, and schemaversion attributes. The file then contains the executed suite tree, optional statistics, and execution errors/warnings. Suite/test elements contain status and execution structure.

<robot generator="..." generated="..." rpa="false" schemaversion="5">
  <suite name="Example" source="..." id="s1">
    ... tests / keywords / messages ...
    <status status="PASS" .../>
  </suite>
  <statistics>...</statistics>
  <errors>...</errors>
</robot>

Do not treat a hand-copied XML fragment as proof by itself. Provenance also needs the command, source revision, framework/interpreter versions, environment inputs, artifact path, and ideally a checksum. The XML proves Robot's recorded execution result; it does not independently prove the external system was trustworthy or that a credential was handled safely.

6. Log, report, and xUnit serve different readers

7. Combine and merge answer different identity questions

Combine says: “these are independent result roots that belong under one reporting umbrella.” Rebot creates a new top-level suite and places the input roots below it. Merge says: “these files describe the same logical top-level suite, perhaps because I reran failures or split execution.” With --merge, matching later test results replace earlier ones; later skipped matches are ignored so they do not erase a real earlier result. Merging requires compatible top-level suite identity.

8. Artifact retention is a separate control plane

A test can pass while artifact upload fails. A test can fail while its evidence is safely retained. Therefore execution status and evidence-retention status are separate controls. Production CI should normally retain the raw machine-readable result needed for diagnosis, publish appropriate HTML/xUnit derivatives, record versions/checksums, and apply access/retention policy based on sensitivity.

9. Why this matters in DevOps

A release gate becomes auditable when the same evidence can be consumed by a human, Rebot, CI, and later incident review. The durable contract is: preserve the original run, identify every derived artifact, make transformation commands reproducible, keep schema/version compatibility explicit, and never let report cosmetics replace source-of-truth status.

10. Knowledge check

11. Summary and next step

You now have the evidence model: execution produces result state; output.xml is the machine-readable artifact; log/report/xUnit are different views or interoperability outputs; Rebot transforms recorded results; combine and merge preserve different identities; and retention/privacy are explicit operational controls. Lesson 2 turns this model into a complete local workflow.

Further reading

• Robot Framework 7.4.2 User Guide — Post-processing outputs — Rebot, combine, merge, and JSON/XML result processing.
• Robot Framework 7.4.2 User Guide — Different output files — output, log, report, xUnit, and output-directory behavior.
• Robot Framework 7.4.2 User Guide — Removing and flattening keywords — output-size and evidence trade-offs.
• Robot Framework 7.4.2 result.xsd — authoritative XML schema version and root attributes.
• Robot Framework 7.4.2 release notes — stable release details and built-in Testdoc deprecation.
• Robot Framework 7.4.2 on PyPI — pinned package metadata and Python requirement.
• Robot Framework releases — re-check stable/pre-release status when updating this chapter.