Parents and children of check-in [0502a93834]
|
2026-08-17
| ||
| 13:13 |
ci: wire the trigger, poll runs, record the verdict as a tag
Completes the loop 0001 §6 describes. The trigger runs after each ingest fold — the moment a check-in becomes visible whatever brought it in, a local commit, a push or a sync. A poller refreshes runs quarry still thinks are going, and a terminal run becomes a tag artifact on the check-in, so CI history clones with the repository instead of living in the forge. The verdict tag is --raw, and that is not a detail: without it the name enters the symbolic namespace where it resolves to a check-in like a release name, and the SECOND check-in to pass would make 'ci-pass' ambiguous for both. zit#80 landed exactly this last night. It is written through the lease holder, like every artifact quarry mints, so two nodes cannot both record a verdict. Proven end to end against the live dagnats: a commit to synthetic launched ci/build.json read AT that check-in, the run was recorded, cancelling it drove the poller to write ci-fail with the run id as the tag's value, and the tag came back through ingest into the index. check-in: e326831901 user: dmestas tags: trunk | |
| 13:02 |
ci: the trigger half of v3 — dagnats is the engine
0001 §6 splits this narrowly: dagnats runs pipelines, quarry notices a check-in and shows the result. quarry defines nothing, schedules nothing, retries nothing. A pipeline is TRACKED CONTENT — ci/*.json in the repository, dagnats' native format — read at the check-in under test, so the pipeline for a historical check-in is the pipeline that ran and there is no forge-side store to drift. Only files directly under ci/ count; a nested path is somebody's fixture. Two behaviours worth naming. First sight of a repository takes the tip as a watermark and launches NOTHING: running a pipeline per historical check-in would be a denial of service against the engine and would say nothing about code nobody just changed — on an imported corpus that is tens of thousands of runs. And an unrecognised run status counts as still running, because claiming a run finished when it has not is how a verdict gets written against a build still going. Verified against the live dagnats for the wire shapes; the trigger itself is covered by tests. check-in: 0502a93834 user: dmestas tags: trunk | |
| 01:12 |
web: a repository has a front door — file browser and README
/r/{repo} was a 404. A repository's landing page was the timeline, which is fossil's instinct rather than a forge's, and there was no way to browse files at all: /file/{hash}/{path} served content only if you already knew the exact path, and nothing linked to it. 0002 §1 lists this as a v1 row that never got built. tree.list turns zit ls's flat path set into one directory level — a store has no directory objects, so a directory is a shared prefix and a count of what is under it — with the directory's README rendered beneath, breadcrumbs, and files linking into the existing highlighted view. The branch selector carries each tip hash, not just the name: zit permits two branches to share a name where forgejo assumes uniqueness, so a name-keyed control would silently pick one. The clone box emits the reader's own host, since a hardcoded base is wrong for every deployment but one. check-in: 7058721205 user: dmestas tags: trunk | |