Git Status Frame
A suite is code, and code lives in a repository. When several people work on the same suite, or when an
AI agent pushes new tests overnight, the copy a controller has
loaded can fall behind what the repository holds, and a run then exercises old tests without anyone noticing.
The opposite happens too: a suite edited on the controller's machine and not yet pushed runs tests nobody else
has. The Git Status panel, in the right pane below the configuration, answers both questions
for every repository a loaded item comes from. It compares each checkout with the main branch of
its remote and shows the result as one row per repository.
The panel appears when a loaded suite, group or test sits inside a git repository. Load the tutorial suite together with two more suites, each cloned from its own repository, and the panel shows three rows. The two extra suites here, Demo and Example, are internal ones used only for this demonstration and are not provided with Orcraft; any suites of your own in their own repositories show the same way:
Each row reads from left to right: a coloured bar and the repository name, a refresh icon, the status chip,
and what the two sides are at. The status is read when the item is loaded and again when the refresh icon is
clicked; it contacts the remote to learn where main is, so it needs network access to the
repository's host.
- Up to date with remote origin/main., in green, means the checkout is at the remote's
main. The row shows the subject of that commit. A run now exercises the suite as the repository holds it. - Behind remote origin/main., in yellow, means someone has pushed to
mainsince the checkout was last updated. The row shows the Remote Hash the branch is at and the Local Hash the checkout is at, and a pull icon appears after the refresh icon. - Ahead of remote origin/main., in the same yellow, means the checkout holds commits that are
not on
main. The suite on this machine is not what the repository publishes, which is worth knowing before a result is shared. There is nothing to pull, so the row has no pull icon.
When a repository tags its releases, the tags take the place of the hashes. A folder that is not a git checkout, or whose remote cannot be reached, shows Unable to access git repo. in grey.
The collapsed panel
Click the arrow before the Git Status title to fold the panel into one line:
The collapsed chip summarizes the rows: green when every repository is up to date, and yellow with a count of the ones that are not. It keeps the state of the lab's suites visible while the rest of the right pane takes the room. Click the arrow again to expand the rows.
Pulling from the controller
Click the pull icon on the Demo suite's row. The panel asks before touching the checkout:
Confirm with Yes. The controller pulls main into the checkout and fetches its
tags, and the row turns green:
The Example suite's row stays yellow, because being ahead is not something a pull resolves: the commits on this machine have to be pushed, or discarded, by whoever made them.
The pull updates the files on disk; the tests already loaded in the tree are the ones read at load time. Click Reload in the tree's action bar to load the suite again from the updated files.
The repository in the results
The same information is recorded with every run. The results tree of the Details dialog carries Repo, Branch, Commit and File Path In Repo columns for each run, recorded from the suite's checkout. A result can therefore always be traced to the exact commit of the test that produced it, which is what makes a failure reproducible after the suite has moved on.
The next page, Details Dialog, opens that dialog at every level of the tree and walks through what it holds.