Node Label Distribution Calculator
Distribute total builds across Jenkins node labels proportionally to each label's weight (executor share).
Inputs
Total builds to distribute across labeled node pools.
Relative weight (e.g. executor count) for the first node label.
Relative weight for the second node label.
Relative weight for the third node label.
Label 1 Builds
625.0builds
Label 2 Builds
250.0builds
Label 3 Builds
125.0builds
Step by step
Sum of weights
5 + 2 + 1
= 8
Label 1 builds = total × (weight ÷ sum weights)
1000 × (5 ÷ 8)
= 625.0 builds
Label 2 builds = total × (weight ÷ sum weights)
1000 × (2 ÷ 8)
= 250.0 builds
Label 3 builds = total × (weight ÷ sum weights)
1000 × (1 ÷ 8)
= 125.0 builds
How it works
When builds are distributed across differently-sized labeled node pools (e.g. `linux`, `windows`, `gpu`) roughly in proportion to each pool's executor capacity, the expected share each label receives is its own weight divided by the sum of all weights, multiplied by the total build volume. This proportional model approximates how Jenkins' load-balancing tends to settle over time for unconstrained builds that could run on any of several labels, though builds hard-pinned to a specific label always route there regardless of relative weight.
Formula
labelBuilds = totalBuilds × (labelWeight / sumOfAllWeights)
- B_t
- Total builds to distribute
- W_i
- Weight (executor count) of label i
- \sum W
- Sum of all label weights
- B_i
- Builds allocated to label i
Frequently Asked Questions
Does this model apply to builds restricted to a single label?
No — this proportional distribution only applies to builds that can float across multiple compatible labels; a build pinned to `agent { label 'gpu' }` always runs on GPU nodes regardless of how the weights compare, so mixed fleets need to separate pinned and floating build populations.
What should I use as 'weight' if not raw executor count?
Executor count is a reasonable default, but weight could also reflect available CPU/memory capacity per label, or a manually assigned priority factor if certain labels should be preferred beyond raw capacity (e.g. cheaper spot-instance labels).
How is this useful for capacity planning?
It helps forecast how added or removed nodes under a given label will shift build distribution — for example, doubling the `windows` label's executor weight roughly doubles its expected share of floatable builds, which helps justify or size a targeted fleet expansion.