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/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/reference/workflow-reference.md +42−2

@@ -410,6 +410,7 @@ letter. At least one job is required.
410 410 | `image` | string | one of `image` / `image-file` | — | Registry image the job runs in. |
411 411 | `image-file` | string | one of `image` / `image-file` | — | Name of a definition under `.vole/images/`. |
412 412 | `runs-on` | string or list of strings | no | any runner | Runner labels the job requires. |
413 | `network` | `none` or `bridge` | no | the runner's setting | Whether the job's container has a network. |
413 414 | `secrets` | string or list of strings | no | none | Repository secrets the job reads, by name. Each name is also the variable a step finds it in. |
414 415 | `env` | mapping | no | none | Environment every step of the job runs with. |
415 416 | `steps` | list | yes | — | Commands the job runs. At least one is required. |
@@ -510,6 +511,42 @@ with a letter or digit.
510 511 See [Runners § Start a runner](../runner.md#start-a-runner) for how a machine
511 512 advertises labels.
512 513
514 ### `network`
515
516 Whether the job's container can reach anything outside it:
517
518 ```yaml
519 jobs:
520 fetch:
521 image: golang:1.27-bookworm
522 network: bridge
523 steps:
524 - run: go mod download
525 ```
526
527 `bridge` gives the container a network. `none` withholds it, and a step that tries
528 to reach out then fails to resolve a host, which is the answer a job that does not
529 need the network should get. Only these two values are accepted; there is no
530 `host`, because a job that shares the runner's network is not isolated from it.
531
532 The job decides, and the machine's own setting fills in only when the field is
533 absent:
534
535 | Job says | Runner can give bridge | Runner cannot |
536 |---|---|---|
537 | nothing | bridge, as the runner was started | none, as the runner was started |
538 | `none` | none | none |
539 | `bridge` | bridge | the job waits for a runner that can |
540
541 A job that asks for `bridge` is only leased to a runner started with
542 `--container-network bridge`, so it waits for a capable machine instead of running
543 without the network it asked for. A job that asks for `none` gets none from either
544 kind of runner, so the same workflow is isolated the same way everywhere.
545
546 A `vole workflow run` applies the same rule: the job's request wins over the
547 command line, and a `bridge` job is refused when the local run was started with
548 `--container-network none`.
549
513 550 ### `env`
514 551
515 552 Environment variables for every step of the job, on top of the image's own. Later
@@ -700,7 +737,8 @@ It does not support:
700 737 Combined results for a commit under review are still produced automatically by the
701 738 server; `on.change-request` is the event trigger, not the combined-result scheduler.
702 739 A local `vole workflow run` ignores triggers and `runs-on`, publishes no artifacts,
703 deploys no site, and has no event payload. It reads the secrets its jobs declare from
740 deploys no site, and has no event payload. It applies a job's `network:` request, so a
741 `bridge` job needs `--container-network bridge` here too. It reads the secrets its jobs declare from
704 742 the instance the checkout's remote names, and leaves the variables unset — with a
705 743 note — where it cannot.
706 744
@@ -712,7 +750,9 @@ note — where it cannot.
712 750 - The commit, workflow blob, image definition, display names, and descriptions are
713 751 pinned when a run is queued. Later edits do not change that run.
714 752 - `vole workflow check` and `vole workflow run` use the same validation as a push.
715 A local run executes in the job's image and ignores `on.push` and `runs-on`.
753 A local run executes in the job's image and ignores `on.push` and `runs-on`; it does
754 apply the job's `network:`, and refuses a `bridge` job when the run was started with
755 `--container-network none`.
716 756
717 757 ## Complete example
718 758