Add runner priority and fallback scheduling #1

Open
opened 2026-05-03 06:21:48 +00:00 by lambadalambda · 0 comments

Problem

Woodpecker currently treats labels as hard filters. In a heterogeneous self-hosted setup there is no way to prefer one matching runner over another, or to fall back to a slower runner only when the preferred runner is unavailable.

Concrete case: we have two linux/arm64 runners:

  • a fast M1 Fedora/Podman runner
  • a slower Ampere runner that is still useful as fallback and also runs linux/arm jobs

Both can match platform=linux/arm64, but Woodpecker has no scheduler weight, priority, or fallback pool. The only current workaround is to remove eligibility from one runner, which means jobs wait instead of falling back.

Desired behavior

Add scheduler policy for runner preference, for example:

  • per-agent priority/weight
  • workflow-level preferred labels with fallback labels
  • runner pools with ordered fallback
  • capacity-aware selection among otherwise matching agents

Why this matters

Labels are good for hard constraints such as platform or repository. They are not enough for operational scheduling policy when runners differ significantly in speed, cost, reliability, or availability.

## Problem Woodpecker currently treats labels as hard filters. In a heterogeneous self-hosted setup there is no way to prefer one matching runner over another, or to fall back to a slower runner only when the preferred runner is unavailable. Concrete case: we have two linux/arm64 runners: - a fast M1 Fedora/Podman runner - a slower Ampere runner that is still useful as fallback and also runs linux/arm jobs Both can match platform=linux/arm64, but Woodpecker has no scheduler weight, priority, or fallback pool. The only current workaround is to remove eligibility from one runner, which means jobs wait instead of falling back. ## Desired behavior Add scheduler policy for runner preference, for example: - per-agent priority/weight - workflow-level preferred labels with fallback labels - runner pools with ordered fallback - capacity-aware selection among otherwise matching agents ## Why this matters Labels are good for hard constraints such as platform or repository. They are not enough for operational scheduling policy when runners differ significantly in speed, cost, reliability, or availability.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
pleroma/woodpecker#1
No description provided.