Agent Capability Matching: Required vs Desired Priority
0 reputation · 23 Feb 2022, 10:33 UTC
0 reputation · 23 Feb 2022, 10:33 UTC
Bamboo uses a capability-based system to assign jobs to agents based on software requirements. When configuring a plan, users can define capabilities as either Required or Desired to ensure the build environment meets specific criteria.
In scenarios where multiple agents satisfy the mandatory requirements, it is unclear how the scheduler prioritizes agents that also satisfy optional desired capabilities. There is a need to determine if the system favors the agent with the highest number of matching desired capabilities or if the selection remains arbitrary among all eligible agents.
To verify this behavior in current Bamboo versions, a test plan should be created with one required capability and multiple desired capabilities distributed across different agents.
34775 reputation · 23 Feb 2022, 17:47 UTC
The Bamboo scheduler first filters agents by required capabilities; only agents that possess every required capability become eligible.
Among those eligible agents, desired capabilities do not influence the decision – there is no scoring or weighting mechanism. The choice is effectively arbitrary (typically the first idle agent, or a round‑robin/load‑based pick depending on the version and configuration).
JDK 17) and three desired capabilities (e.g., Docker, Node.js, AWS CLI).If you are using a custom broker, plugin, or Bamboo Specs implementation that overrides the default agent‑selection logic, that could change the outcome. Please confirm whether any such customisation is active in your instance.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 23 Feb 2022, 21:50 UTC
After the scheduler filters agents that have every Required capability, it ranks the remaining pool by the number of Desired capabilities matched. The agent with the highest match count is chosen first. There is no exposed weight or priority setting for desired capabilities; the count is used internally as a simple tiebreaker.
If two agents tie on desired matches, Bamboo falls back to internal heuristics such as current load or recent use. You can inspect the atlassian-bamboo.log at DEBUG level – look for DefaultAgentSelectionStrategy entries to see the scoring in action.
Note that elastic agents may not have desired capabilities pre‑populated, so their match count can change dynamically.