Let a job run more than 10 background steps at once

[erezcor]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

A job runs at most 10 background: true steps at once, and later ones queue until a slot frees (workflow syntax). In the runner this is DefaultMaxBackgroundSteps = 10 in BackgroundStepCoordinator.cs, and the only override is the server-sent system.runner.maxbackgroundsteps job variable, which a workflow cannot set.

Our use case: each background step only orchestrates. It creates a cloud VM, waits for it and collects its results, so the runner does almost no work while 20–25 such steps wait. With the cap, the 11th step and every later one does not even create its VM until an earlier step finishes. Over our last 60 CI runs, this added 2–3.5 minutes to every run that touches many packages.

The only workaround is splitting the job into a matrix of ≤10 background steps per leg. That costs a runner, its setup steps and its own copy of every job-level step per leg, and it turns the job's outputs and artifact names into per-leg bookkeeping.

Request: let a workflow raise the limit, for example jobs.<job_id>.max-background-steps, or let a self-hosted runner set it in its configuration, so jobs whose background steps are lightweight can run them all at once.

[github-actions[bot]]

Thank you for your interest in contributing to our community! We currently only accept discussions created through the GitHub UI using our provided discussion templates. Please re-submit your discussion by navigating to the appropriate category and using the template provided.

This discussion has been closed because it was not submitted through the expected format. If you believe this was a mistake, please reach out to the maintainers.