Calculate how build jobs distribute across labeled Jenkins agent pools.
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.
labelBuilds = totalBuilds × (labelWeight / sumOfAllWeights)
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.
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).
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.