Sign in

Search issue titles and bodies, change requests and comments. Private repositories you cannot read are not included.

vole
Clone

Read only, no credentials:

https://rodent.software/git/vole.git

Write over SSH with a registered key:

git clone ssh://git@0.0.0.0:2222/vole.git

A free and open-source forge that lives in your Git repo.

Store CI run records in the database, not the repository

b312e1660ac3d570fc35350a22b3514c56ab466f · Keenan Nemetz · 11d ago · parent db5e4382

Store CI run records in the database, not the repository

A finished attempt was a set of files on the vole branch: a record, step
ranges, and artifact pointers, pushed as a commit. At 959 files, CI records
were 849 of them, and every human metadata write had to carry them.

The runner now sends the record with its finish message over the SSH channel
that holds the lease. The server checks the account, the job, and the log and
artifact pointers, then writes the attempt, steps, artifacts, attestation, and
run result in one transaction in data/runs.db. A tagged build still pushes its
release pointers to the branch after the record is stored.

Pre-receive refuses a new runs/ file. vole admin index rebuild imports records
still on an old branch; records written since are never deleted by a rebuild.
The run page reads the stored attempt, and runs.db is now a source that must be
backed up.

This stops new CI history from entering Git. Existing commits keep the records
they already have; removing those would require rewriting the protected vole
branch, which this change does not do.

docs/workflows.md +7−6

@@ -245,10 +245,11 @@ git tag -a v1.0.0 -m "first release" # needs notes and a tagger
245 245 git push origin refs/tags/v1.0.0 # the runner builds and publishes
246 246 ```
247 247
248 The record on the `vole` branch names the build (`release: v1.0.0 artifacts from
249 run 01M5...`), so `git log vole` shows which run shipped the files. A lightweight
250 tag is refused: it has no release notes and no tagger. A tag run never counts as a
251 branch's required check, even if the tag points at that branch's tip.
248 The release commit on the `vole` branch names the run that produced the files
249 (`release: attach ... from run 01M5...`), so `git log vole` still shows which build
250 shipped them. The run's full record is in `data/runs.db`, not on the branch. A
251 lightweight tag is refused: it has no release notes and no tagger. A tag run never
252 counts as a branch's required check, even if the tag points at that branch's tip.
252 253
253 254 See [Releases](releases.md) for the release page and artifact rules.
254 255
@@ -280,8 +281,8 @@ instance (`pages_ref`), not by the workflow.
280 281 ## What happens to a queued workflow
281 282
282 283 Pushing again cancels queued runs for the commit it replaced. It never cancels a
283 run that is already in progress. Finished runs become records on the repository's
284 `vole` branch.
284 run that is already in progress. Finished runs are stored in `data/runs.db`, not on
285 the repository's `vole` branch.
285 286
286 287 For what happens when a runner disappears, how work is requeued, and how finished
287 288 history is rebuilt, see [Runners § Scheduling and the queue](runner.md#scheduling-and-the-queue).