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). | |