Details Dialog

The execution tree shows what happened in numbers: planned, done, passed, failed. The Details dialog shows what happened in full. It opens on any row of the tree and gathers everything that belongs to that row's scope: the configuration of every item in it, with default, planned and run values side by side, and a results tree that goes down through cycles, cases, case cycles, flows and steps, with the status, timing and descriptions of each. Earlier pages opened it on single tests; this page opens it at the other levels and walks through its parts.

The session in the controller is a workspace. It holds every suite and test loaded, relevant to the question at hand or not, and a run of a whole suite mixes hundreds of results. The Details dialog is the tool that scopes that workspace to a chosen level and summarizes it there, which is why it exists at every level from the session row down to a single case, and why its exports are the way results leave the controller.

To have something to look at, run the five tests of the Statuses and Results group with their folders set as on Orcraft Statuses: the group then holds a pass with warnings, a failure, an error, a partly failing checkpoint run and a passing run with result fields.

The session level

Double-click the Session row at the top of the tree. A double-click on any row opens the dialog for that row; the Details button in the action frame does the same for the selected row:

The left half, Session Configurations, nests the configuration of every loaded item: the suite, each group in it, each test in the group with its Default Value, Plan Value and Run Value columns. The right half, Session Results, starts with the summary strip the tree also shows and then lists every item as a tree. Tests that have not run appear with Not Run rows for the cases they plan, so the scope is complete rather than limited to what has happened.

At the bottom, the Items Filter counts the rows of the results tree by status: Pass, Warn, Fail, Error, Not Run and All. The counts are rows, so a case and its case cycle count twice; they are there to say how much of each kind the tree holds and to narrow it.

The group level

Close the dialog, select the Statuses and Results group and open Details again. Then click the Fail chip:

The dialog is now scoped to the group: its description and its tests' configurations on the left, and only the group's results on the right. With Fail active the tree keeps the rows that failed and the rows above them, so the failing cases of Status: Fail and Checkpoints are listed together with the test runs they belong to and nothing else. Click All to restore the tree. The chips work the same way as the status chips above the execution tree, one level deeper.

The test level

Open Details on Status: Fail:

A test's dialog adds what only a test has: the Test Description from the config class, the List Dimensions table with the default, planned and run values of each matrix dimension, and the case table with a Planned and a Run check per case. The results tree runs from the test run through its cycle to every case and case cycle, and further down to flows and steps when the test has them. Scrolling the tree to the right reveals the columns every row carries: the endpoint, the status, the start and finish times and the elapsed time, the error, failure and warning descriptions, the repository, branch and commit of the test, and any result fields the test declares.

The buttons above the tree help with large scopes. Refresh re-reads the results while a run is still going, the − and + buttons collapse and expand every row, and the tree's own arrows fold single branches.

The test run level

A test keeps every run it has made as a Test Run row beneath it, the older ones greyed as superseded. The test level gathers all of them; a run row scopes the dialog to one. Run Status: Fail a second time, select the newer run row and open Details on it:

The title says Test Run, and the results tree starts at that one run rather than at the test, so its counts and its Items Filter cover this run alone. The Run Value column on the left holds what this run actually used, which matters when the plan has changed since: a run keeps its own configuration, and its dialog shows that one. The run row also carries a Planned column saying whether the run was made with the planned configuration or with values edited on the run itself. This is the level to open, and to export, when one run is to be reported or handed to an AI agent for a look at a failure.

Exporting the scope

The two buttons at the bottom left take the dialog's scope out of the controller.

Export to XLSX

Export to XLSX writes a workbook with the summary, the configurations and the results tree of the scope, every column included. It is the format for a report or for analysis in a spreadsheet.

Export for Agents

Export for Agents writes a folder with a summary.txt of the scope and a logs folder holding the run logs of the scope with their colour codes stripped. It is the format for handing results to an AI agent, which reads plain text better than a workbook and needs the logs next to the summary to explain a failure.

Both exports contain exactly what the dialog shows, at the level it was opened on. Opening it on the session exports everything; opening it on one failing test exports that test.

The dialog gathers the logs it exports from the same place the controller shows them. The next page, Log Frame, is about that place.