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.
Rewrite the README around the new tagline
e73d453fe4edf2d95ec7e178dad0c232b5ece1c7 · Keenan Nemetz · 2d ago · parent 18c559ea
Rewrite the README around the new tagline "A forge that lives in your Git repo" replaces "A small but mighty software forge that lives in your Git repository" everywhere it is the brand line: the README, the docs index, and the .deb/.rpm description. The built-in landing-page tagline becomes the same sentence, so a new instance shows it without config. The package description said CI records live in Git. They live in data/runs.db, so it now says CI history stays on the instance, and it names comments, which do live in the vole branch, and says reviews where it used to say approvals. The README is the front page and nothing else: the tagline, why the project is worth using, and links. The quick start, the documentation table, and the browser sign-in setup move out; the first two are already in the docs, which the README now links. Development notes move to DEVELOPMENT.md. The private repository 404 note is dropped because docs/accounts-and-access.md covers it, and Contributing no longer tells coding agents to read AGENTS.md.
DEVELOPMENT.md +41
| @@ -0,0 +1,41 @@ | |||
| 1 | # Developing Vole | ||
| 2 | |||
| 3 | ## Build | ||
| 4 | |||
| 5 | ```sh | ||
| 6 | go build -tags libsqlite3,sqlite_fts5 -o vole ./cmd/vole | ||
| 7 | ``` | ||
| 8 | |||
| 9 | Vole links SQLite dynamically, so a build needs a C compiler and the SQLite | ||
| 10 | development headers (`libsqlite3-dev` on Debian and Ubuntu, `sqlite-devel` on | ||
| 11 | Fedora and RHEL). The library must be built with FTS5, which the distributions | ||
| 12 | above enable; global search uses it. The binary needs `libsqlite3.so.0` on the | ||
| 13 | machine that runs it. `go.mod` pins the Go toolchain, so an older `go` on your | ||
| 14 | `PATH` fetches the right one on the first build. | ||
| 15 | |||
| 16 | ## Test | ||
| 17 | |||
| 18 | ```sh | ||
| 19 | go test -tags sqlite_fts5 ./... | ||
| 20 | ``` | ||
| 21 | |||
| 22 | ## Before you push | ||
| 23 | |||
| 24 | ```sh | ||
| 25 | vole workflow run verify | ||
| 26 | ``` | ||
| 27 | |||
| 28 | `verify` is everything CI runs: formatting, vet, build, the license and | ||
| 29 | vulnerability scans, the packages, the deployment files, Markdown links, and the | ||
| 30 | tests. Its steps live in | ||
| 31 | [`.vole/workflows/verify.yaml`](.vole/workflows/verify.yaml), so a local run and a | ||
| 32 | pushed run execute the same commands in the same image. That means it needs a | ||
| 33 | container runtime (Docker, Podman, or nerdctl) rather than the tools on your | ||
| 34 | `PATH`, and network access for module downloads: the job declares | ||
| 35 | `network: bridge`, so the runner that takes it is started with | ||
| 36 | `--container-network bridge`, and a local run defaults to the same network. | ||
| 37 | |||
| 38 | ## Using Vole as a library | ||
| 39 | |||
| 40 | Vole is also a Go library. See | ||
| 41 | [Architecture § Using Vole as a library](docs/architecture.md#using-vole-as-a-library). | ||