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.
README.md +7−6
| @@ -3,15 +3,16 @@ | |||
| 3 | 3 | **A small but mighty software forge that lives in your Git repository.** | |
| 4 | 4 | ||
| 5 | 5 | Vole is for developers who value ownership, simplicity, and resilience over feature | |
| 6 | count. Code, issues, change requests, approvals, releases, and CI records live in | ||
| 7 | Git. Runners run where you put them. There is no control plane in a data center | ||
| 8 | you do not own. | ||
| 6 | count. Code, issues, change requests, approvals, and releases live in Git. CI | ||
| 7 | history lives in the instance's database. Runners run where you put them. There is | ||
| 8 | no control plane in a data center you do not own. | ||
| 9 | 9 | ||
| 10 | 10 | ## Why Vole | |
| 11 | 11 | ||
| 12 | - **Your repository survives outages.** Issues, reviews, approvals, releases, | ||
| 13 | and build records clone with the code, so they are not trapped in a vendor's | ||
| 14 | database. When a hosting service goes down, your repository does not. | ||
| 12 | - **Your repository survives outages.** Issues, reviews, approvals, and releases | ||
| 13 | clone with the code, so the work that belongs to the repository is not trapped | ||
| 14 | in a vendor's database. CI history stays on your instance and is backed up with | ||
| 15 | it. When a hosting service goes down, your repository does not. | ||
| 15 | 16 | - **CI is not tied to a vendor.** Add a workflow, start a runner anywhere it can run | |
| 16 | 17 | an OCI runtime (Docker, rootless Podman, or nerdctl), and Vole sends it work over | |
| 17 | 18 | SSH. Your build machines can be a server, a spare desktop, or a box in the closet. | |