v2.76.0
Binaries and the merged-pull-request list are on the GitHub releases page.
Lanes
A plan of fifty jobs, fanned out as fifty GitHub jobs, spends most of its time
on runner setup and runner slots. A lane groups jobs into one runner:
orun run --lane <id> runs every job of the lane in-process, each as soon as
its upstreams finish. See Lanes.
execution:
lanes:
mode: auto
maxLanes: 16
rules:
- when: { triggerRef: github-pull-request }
mode: job
- Modes:
job,component,envandauto. Groups andlane: isolatedgo on components, andrulespick the mode per trigger. - Auto mode without weights.
- A plan of at most
maxLanesjobs keeps one lane per job. - A larger plan is shared out per environment and runner, keeping
dependency chains in one lane, and packed into at most
maxLaneslanes.
- A plan of at most
- What a lane never does: mix environments or runners, put an
isolatedcomponent with anything else, or form a cycle. A cycle created by grouping is split by level and reported. UnderonCycle: rejectororun plan --strict-lanesit fails the plan instead. orun plan --view lanesshows the layout, and the plan summary gains alanesline.orun run --lane <id>- Runs the lane at its concurrency.
- Upstreams in other lanes are awaited through remote state without holding a slot.
- With local state, the run refuses and names the lane to run first.
--retry --lanere-opens only the lane's failed jobs.
- GitHub Actions
--github-outputaddslane-matrixandlane-count.- A multi-job lane posts one check run per job, named by the job's check
title, so branch protection keeps working. This needs
permissions: checks: write;ORUN_CHECK_RUNS=0turns it off. - Concurrent jobs print their step groups together, and the lane writes a per-job table to the step summary.
Backward compatible
Without execution.lanes, a plan is byte-identical to v2.75.0's, and
matrix and --job are unchanged. --lane <id> on a plan without lanes is
--job <id>, so a workflow can move to lane-matrix + --lane before it
adopts any lane configuration. Older orun ignores the new plan fields.