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

Code

396 commit(s) on main

Compare History
Turn off the disk reserve for test-spawned runners Keenan Nemetz · 30m ago c284cb2c
source preview history blame raw 2.4 KiB

Deployment files

The files here put a Vole instance on a fresh machine. The guides are in docs/deploy; this page is what is in the box.

Path What it is
cloud-init/vole.yaml The forge’s first-boot file. Installs the package, writes the configuration, creates the instance admin, starts the service
cloud-init/runner.yaml The CI runner’s first-boot file. Rootless Podman, an unprivileged account, a pinned host key, and the unit enabled
cloud-init/render.sh Fills either file in from the environment, for pasting into a provider’s user-data field

Cloud-init is the whole deployment story, and it is deliberately the only one. A Vole instance is one package, one configuration file, and one directory on local disk, so a first-boot file that installs the package and writes the configuration is everything that happens inside the machine. What a provider configuration would do outside it — a firewall, an address, a DNS record — is three fields in a console the operator already has open, and a container would add a layer without removing one: it loses the unit’s hardening, and it cannot run the CI half, which needs an OCI runtime of its own.

Three things are deliberate:

  • One first-boot file per role. The two templates differ in what they install and which account they create, and nothing else. Neither has a copy of the other’s setup steps.
  • No machine images. A golden image per cloud would need a publishing pipeline and a per-cloud import, and it would go stale between releases. Installing a .deb during first boot takes about thirty seconds and always installs the version you named.
  • Nothing here runs twice. First boot happens once; changing the instance afterwards is editing /etc/vole/vole.toml and restarting, and upgrading is a package install. See Packages.

The runner’s unit and its configuration example ship in the package, not here: packaging/systemd/vole-runner.service and packaging/runner.env. One binary is the forge, the runner, the CLI, and the library, so one package carries both units.

scripts/check-deploy.py and the deployment files step in .vole/workflows/verify.yaml check these files on every push: the YAML parses, each template renders with no placeholder left behind, the boot scripts are valid sh, and the runner’s template, unit, and packaged example agree. It needs no cloud credentials and no network.