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.

#159

P2: A job can declare the network it needs

closed · opened by keenan 7d ago

keenan opened this 7d ago

Why

A job that fetches dependencies needs a network; a job that only compiles a tree does not, and giving it one weakens the only boundary a step has. Today the choice is made once per machine, by vole runner --container-network, so a runner that takes one job needing the network gives the network to every job it takes. docs/runner.md said “add bridge only when a job needs it”, which no workflow could express: the job had no say, and a job that did need one could be handed to a machine that had none and fail for a reason the author could not see.

This is §5 of #138 (“a way for a job to declare network and resource needs instead of making them runner flags”). It is also the first thing an LLM coding-agent workflow needs from the queue, but the field is general: a deploy, a release, and any go mod download want the same promise.

Scope

  • network: none | bridge on a job, validated at push time so a value no runner can satisfy fails the push rather than leaving the job queued forever.
  • Pin the request with the run, so a workflow edited after enqueue cannot change what a queued job is allowed to reach.
  • Lease a bridge job only to a runner that advertises it, and to any runner otherwise: a job that asks for nothing keeps the runner’s own default.
  • Apply the job’s request in the runner, and refuse a bridge job on a runner that cannot provide one instead of running it without the network it asked for.
  • Apply the same rule in vole workflow run, so a local run either matches CI or says what to change on the command line.
  • Show it: the workflows page says what a job asks for, the run page says what the run declared, and the runner’s log line names the mode it used.
  • Document it in docs/workflows.md, docs/reference/workflow-reference.md, and docs/runner.md, including the two places that claimed a job could already ask.
  • The repository’s own verify and release workflows declare network: bridge instead of relying on how their runner was started.

Not in this change: per-job CPU, memory, or PID limits (§5, same shape, separate field), and any queue priority for a bridge job that is waiting for a capable runner.

Acceptance criteria

  • vole workflow check accepts none and bridge and rejects any other value, naming the field.
  • A network: bridge job is never leased to a runner started with --container-network none. It waits, and the runner’s startup line says what that machine can provide.
  • A network: none job never gets a network, even from a runner that could give one.
  • A job that declares nothing behaves exactly as it did before this field existed.
  • vole workflow run of a network: bridge job fails with a message naming --container-network when the run was started without one.

Related

  • #138 tracks the rest of the format gaps; this closes the network item.

Comments (1)

keenan 7d ago

In review as #160 (01M6F5WFDH4SCB080WJGNR0K2Z). The push run and the combined result both pass, and the review covers the format, the queue match, the runner, the local run, the UI, and the docs. One item from the checklist is deliberately not in it:

  • verify and release declare network: bridge.

The instance validates a pushed workflow with the binary it is running, and that binary predates the field, so a commit that adds network: bridge to either file is rejected by pre-receive until the instance runs this build. That is the upgrade step, not a design question: rebuild, restart vole.service and vole-runner.service, then a second small change adds the two declarations and flips the README sentence back.

Everything else on the list is in #160:

  • network: validated at push (ci/workflow.go), any other value naming the field.
  • The request pinned with the run and matched at the lease, so a bridge job waits for a capable runner and is never handed to a closed one.
  • The runner applies the job’s request, so a bridge runner withholds the network from a job that asked for none, and refuses a bridge job it cannot provide.
  • vole workflow run applies the same rule and names --container-network when it cannot.
  • The workflows page, the run page, and the runner’s log line say what was asked for and what ran.
  • Docs: the field table and a network section in the reference, the guide, and the runner page, including the removal of the two claims that a job could already ask.