We have a compiler on our remote agents that uses a floating license. Only a single agent can use this license at a time.
When one agent is building and another requests the license, the build fails. I would prefer that the build be queued until the license becomes available.
Is there any way to support this behavior?
You say that you use remote agents - I assume that you have multiple agents (like for example 5 or 10), not a single one. So, I was wondering if you need to all of those agents to pickup the 'floating license' jobs, or would it be possible to lock-down single agent to the jobs that need the floating license.
What would you say?
Yes, I have multiple remote agents. All of my agents have the same capabilities. I am trying to minimize build queue times on our farm by creating redundant agents
If I define the "floating license" as a capability on a single agent this would technically solve the problem. However then I would also need to prevent build plans that do not require this capability from executing on the special agent. Otherwise they would interfere with build plans that do require the capability.
> However then I would also need to prevent build plans that do not require this capability from executing on the special agent. Otherwise they would interfere with build plans that do require the capability.
This can be done too. You can define another capability on the agents without licence and require that on Jobs that do not require the floating licence. The net effect: Jobs that need licence queue on the single agent, all the others Jobs build on the 'noLicence' agents. I realise it is far from perfect if you have a lot of Jobs
Better support for assigning agents to Jobs is something we are definitely intending to add to the product, as you are not the only person asking for such a feature.
Is there any progress on such a feature? We have a number of examples of this. In particular, some of our regression tests involve multiple machines, and not always the same combination of machine (i.e. we can't dedicate all of the resources to a single agent, since it would force jobs which require disjoint subsets of the resources from executing in parallel). The potentially disjoint resources include software too licenses, hardware, network bandwidth through a switch, etc.
Bamboo 5.9 will no longer be supported after June 12, 2017. What does this mean? As part of our End of Life policy, Atlassian supports major versions for two years after the first major iteratio...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot