Reference · page 17 of 17
What your CI must publish
DoneMark never runs your tests. It reads what your CI published about a run that already happened. This is the short form of what it looks for.
The full document, with every field and the checks that hold it true, is the archive contract. It was read out of the two reporters that already exist, unedited, so it describes what works rather than a wish — which is what makes it something a third reporter can be written against.
What is the reporter, and why does this project need one?
DoneMark never runs your tests; it reads what your CI published. The reporter is the small part of your CI that publishes it: after the tests run, it writes one entry per check into a file named constat-check-report. Without it, DoneMark sees that CI ran but not what any check said, so no criterion can be seen passing. Installing it does not change how your tests run.
The five artefacts
Each is a workflow artifact, uploaded by the run that gated the commit. The name is the interface. Renaming one breaks the evidence path.
| Artefact | Carries | Without it |
|---|---|---|
constat-check-report | One entry per check the suite ran, at this commit. | DoneMark witnesses no criterion at all. |
constat-check-report-base | The same checks run against the code as it was before the change. | A check cannot be shown to have been failing first. |
constat-check-coverage | Which lines each test file was observed executing. | DoneMark cannot say whether a check touches what changed. |
constat-check-report-mutation | What each check did while a line the change added was deliberately broken. | DoneMark cannot say whether a check notices a break. |
constat-pictures | One picture per check that took one. | A criterion about a screen reads as unproven. |
The first is required. The rest each remove one rung from the ladder rather than stopping DoneMark entirely, and their absence is said plainly rather than guessed around.
The report
checks.json, with a schema of constat.check-report/v1 and a checks array. Each entry:
| Field | Required | Meaning |
|---|---|---|
name | yes | The check's full name — the exact string your test run reports. This is what a criterion's named check is matched against. |
status | yes | passed, failed, skipped, or could_not_run. |
file | yes, may be null | The test file, relative to the repository. |
picture | no | The picture this check took, as a bare file name. |
message | no | The first line of the error, in CI's own words. |
line | no | Where the failure came from, if your reporter knows. |
skipped is never folded into passed. A check that asserted nothing shows nothing, and the record says so.
If the report is not this
DoneMark witnesses nothing for that run and says so on the project's health line, in the collector's own words. It does not guess at a report it cannot read.
Which languages have one today
Node, Elixir and Python ship with reporters DoneMark's connect tool writes for you. Go, Rust and Ruby do not yet — the new-project door prints that plainly rather than letting you discover it after an attempt.
Anyone can write one for any language: that is what the contract is for.