Verdict for any repo

Cloud testing used to serve one repository. It now serves any GitHub repository you administer: the repository declares its own checks, the fleet runs them, and you get PASS, FAIL or UNKNOWN back for a commit. Nothing about the repository needs to know about Omniscio.

Connect the repository

Connecting a repository is not open to everyone yet, so the card arrives hidden. Turn it on in Settings → Lab under Repositories connected to cloud testing first. Once it is on, open Settings → Diagnostics and find Repositories connected to cloud testing under the cloud testing preference row.

1. Type the repository as owner/name and press Connect.
2. Omniscio asks GitHub, in that moment, whether you are an admin of it. Your GitHub sign-in is used once for that check and is never stored.
3. The repository appears in the list. Disconnect stops it using cloud testing; its code copies and answers leave the fleet within seven days.

Only an admin of a repository can connect or disconnect it, and only people GitHub confirms can use it can ask it questions.

Write the repository's verdict.json — one command

A repository declares its checks in a file called verdict.json at its root. You do not have to write it by hand: run

verdict init

in the repository. It looks at what the repository already has — its package.json scripts and dependencies, or the usual Python test files — and writes one check named tests.

What it finds	The command it writes
vitest	npx vitest run --reporter=junit --outputFile=verdict-junit.xml
node --test	node --test --test-reporter=junit --test-reporter-destination=verdict-junit.xml
pytest	python -m pytest --junitxml=verdict-junit.xml
jest with the jest-junit reporter installed	JEST_JUNIT_OUTPUT_FILE=verdict-junit.xml npx jest --reporters=default --reporters=jest-junit

verdict init refuses to overwrite a verdict.json that is already there, so edit the file by hand if you want more than one check. It also refuses jest when jest-junit is not installed and tells you the one line to run, because jest cannot write the JUnit report Verdict reads on its own.

What a check gets — and does not get

A check runs with no network and no secrets. By design: whatever a check needs must be in the repository and its lockfile. A check that tries to open an outside connection is refused, and so is one that reads a fleet or developer secret.

A check is also not given the Omniscio app. The command line works on a computer with the app closed; late answers still reach a session when the app is running.

What you get back

• PASS — the command exited cleanly and its report shows at least one test that ran and none that failed.
• FAIL — the report names failing tests, so a FAIL lists what broke and you do not have to re-run locally to find out.
• UNKNOWN — no usable report, a report that does not match its own totals, a timeout, or a check the file does not declare. A report that is missing, empty or unreadable is never a PASS.

The file, if you do want to write it yourself

{
  "version": 1,
  "checks": {
    "tests": {
      "run": "python -m pytest --junitxml=verdict-junit.xml",
      "report": "verdict-junit.xml",
      "timeoutSeconds": 600
    }
  }
}

run is the shell command, report is a path inside the repository holding the JUnit XML the command wrote, and timeoutSeconds is optional (1 to 600). Check names are lowercase letters, digits and hyphens. An unknown name is refused rather than answered PASS.

Limits worth knowing

• node --test writes JUnit on Node 20.11 and later. On an older Node, use a different runner or a report converter.
• jest needs jest-junit in the repository; verdict init says so rather than writing a check that could never produce a report.
• A check runs the whole declared check. Naming individual files inside a command check is not supported.
• Connecting is currently done in the app. The standalone command line runs the repository's checks; connecting a repository from it is not available yet.
• The card is a developer surface: it is shown only in an unpackaged development build, with the Lab switch on.
• What the coordinator says about a refusal reaches you as a short, fixed sentence chosen from a known set of reasons. Its raw response body never leaves the app: a machine reason is kept only when it is a bounded token, and an error page that cannot be read as JSON is recorded in the debug log with its HTTP status and dropped.