vole
Clone
Read only, no credentials:
https://rodent.software/vole.git
Write over SSH with a registered key:
git clone ssh://git@rodent.software:2222/vole.git
A free and open-source forge that lives in your Git repo.
| 1 | # Deployment files |
| 2 | |
| 3 | The files here put a Vole instance on a fresh machine. The guides are in |
| 4 | [docs/deploy](../docs/deploy/README.md); this page is what is in the box. |
| 5 | |
| 6 | | Path | What it is | |
| 7 | |---|---| |
| 8 | | `cloud-init/vole.yaml` | The forge's first-boot file. Installs the package, writes the configuration, creates the instance admin, starts the service | |
| 9 | | `cloud-init/runner.yaml` | The CI runner's first-boot file. Rootless Podman, an unprivileged account, a pinned host key, and the unit enabled | |
| 10 | | `cloud-init/render.sh` | Fills either file in from the environment, for pasting into a provider's user-data field | |
| 11 | |
| 12 | Cloud-init is the whole deployment story, and it is deliberately the only one. A |
| 13 | Vole instance is one package, one configuration file, and one directory on local |
| 14 | disk, so a first-boot file that installs the package and writes the configuration |
| 15 | is everything that happens *inside* the machine. What a provider configuration |
| 16 | would do outside it — a firewall, an address, a DNS record — is three fields in a |
| 17 | console the operator already has open, and a container would add a layer without |
| 18 | removing one: it loses the unit's hardening, and it cannot run the CI half, which |
| 19 | needs an OCI runtime of its own. |
| 20 | |
| 21 | Three things are deliberate: |
| 22 | |
| 23 | - **One first-boot file per role.** The two templates differ in what they install |
| 24 | and which account they create, and nothing else. Neither has a copy of the |
| 25 | other's setup steps. |
| 26 | - **No machine images.** A golden image per cloud would need a publishing pipeline |
| 27 | and a per-cloud import, and it would go stale between releases. Installing a |
| 28 | `.deb` during first boot takes about thirty seconds and always installs the |
| 29 | version you named. |
| 30 | - **Nothing here runs twice.** First boot happens once; changing the instance |
| 31 | afterwards is editing `/etc/vole/vole.toml` and restarting, and upgrading is a |
| 32 | package install. See [Packages](../docs/packaging.md). |
| 33 | |
| 34 | |
| 35 | The runner's unit and its configuration example ship in the package, not here: |
| 36 | `packaging/systemd/vole-runner.service` and `packaging/runner.env`. One binary is |
| 37 | the forge, the runner, the CLI, and the library, so one package carries both |
| 38 | units. |
| 39 | |
| 40 | `scripts/check-deploy.py` and the `deployment files` step in |
| 41 | `.vole/workflows/verify.yaml` check these files on every push: the YAML parses, |
| 42 | each template renders with no placeholder left behind, the boot scripts are valid |
| 43 | `sh`, and the runner's template, unit, and packaged example agree. It needs no |
| 44 | cloud credentials and no network. |
| 45 |