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.

Let a job declare the network it needs

d79580247b8f33f7ffdf2f05847733cad12c187a · Keenan Nemetz · 6d ago · parent 4ac42680

Let a job declare the network it needs

A runner's --container-network decided the network for every job it took, so a
machine that could reach the network gave it to builds that never asked, and a
job that did need one could be handed to a machine that had none. The docs said
"add bridge only when a job needs it", which no workflow could express.

A job now says `network: none` or `network: bridge`. The request is pinned with
the run, and the lease only hands a bridge job to a runner that advertises the
capability, so a job waits for a capable machine instead of failing on one that
never could. The runner applies the job's request to its container, which means a
bridge runner can still withhold the network from a job that asked for none.

A job that declares nothing keeps the runner's own setting, which is what every
workflow meant before this field existed. The local run applies the same rule and
refuses a bridge job when it was started without one, so `vole workflow run` either
matches CI or says what to change on the command line.

The workflows page, the run page, and the runner's log line now say what a job
asked for and what it ran with. verify.yaml and release.yaml are deliberately not
in this change: the instance validates a pushed workflow with the binary it is
running, so they can declare the field once that binary knows it.

Closes #159.

docs/workflows.md +11−1

@@ -65,6 +65,15 @@ executes the selected jobs in that order.
	65	65	can run anywhere. See [Runners § Start a runner](runner.md#start-a-runner) for what the
	66	66	labels mean on the machine.
	67	67
		68	A job's network is closed by default: the container gets whatever the runner can
		69	offer, and a runner with no network is the normal case. `network: bridge` asks for
		70	one, which a job that downloads dependencies needs, and only a runner that can
		71	provide it takes the job. `network: none` withholds it, so a job that should not
		72	reach out fails to resolve a host instead of quietly succeeding, even on a machine
		73	that could have given it a network. Declaring the field makes the job behave the
		74	same way everywhere instead of depending on which runner picked it up. See
		75	[Workflow reference § network](reference/workflow-reference.md#network).
		76
	68	77	When a push starts a job, Vole remembers the exact commit, the exact workflow
	69	78	file, and the exact image definition. Editing any of them later does not change a
	70	79	job that is already queued.
@@ -365,7 +374,8 @@ variables: the image's `env:` (or the step) decides whether `/cache` is used. Se
	365	374	`--no-cache` empties it after every job.
	366	375
	367	376	A local run still ignores triggers and `runs-on`, publishes no artifacts,
	368		and deploys no site. It sets `CI=true` and `VOLE_CI=1`, gives each step its
		377	and deploys no site. It does apply the job's `network:` request, so a `bridge` job
		378	needs `--container-network bridge` here too (the default). It sets `CI=true` and `VOLE_CI=1`, gives each step its
	369	379	declared timeout, and reads no standard input. It reads the secrets its jobs declare
	370	380	from the instance the checkout's remote names, with your own credential, so a job
	371	381	that deploys behaves the same here as it does on a runner. Where it cannot — no