Agent Priorities and Agent Based Variables
Asked by Cameron Ferguson:

I guess this is more of a feature request rather than seeing if it's possible. But maybe it is already possible and I just don't know it yet. This is a 2 part question...

Agent priorities? Is it possible to say that if I have Agents A, B, \& C that can all be used to run a job, but if Agent B is available, i want to make sure and use that one before I use Agents A or C? We are considering using our developers computers as agents, but would want to make sure they are only used when our actual build computers arent.

Second question is around Agent based variables... Is it possible to have bamboo variables for specific agents that I can use like other bamboo variables? Same example with Agents A, B \& C... Agent A may be a much faster computer than A and C, so having the possibility to specify the number of CPUs used in the compilation would be different per agent that is spawning it (I know there are other ways around this specific example, but just using it for the basis of my question)

Thanks in advance


Answers:
author: ReneR
body: 1. Create a bamboo-capabilities.properites file with this content:

agent.max_jobs=8

2. Put this file in your AGENT_HOME. Restart the agent

3. Set a requirement for the job you require to run with 8 CPUs

4. In your task, you use the command line exactly as you described "make ${bamboo.agent.max_jobs}

On the job you want to run with 6 then your capability file will just have a different value which will get passed to the build.

If you want a job to ALWAYS run with 8 CPUs then have the requirement match the VALUE of the property exactly. I.e. "capability equals EIGHT" or something like that (I think capablity values are string matched not numerically matched)

If you want the job to run on ANY agent but to use only the CPUs it is capable of doing then have the requirement only match the presence of the capability and not its value. i.e. "capability exists"

Is this not what you meant by a "Bamboo solution"?


author: ReneR
body: There's a recent question around agent-specific capabilities:

[https://answers.atlassian.com/questions/18586/can-a-remote-agent-declare-its-own-custom-capabilities](/questions/18586/can-a-remote-agent-declare-its-own-custom-capabilities)

Check that out and the page it points to: <http://confluence.atlassian.com/display/BAMBOO/Configuring+Remote+Agent+Capabilities+via+bamboo-capabilities.properties>

As for the first part of your question, no. There's no way I can think of to have a 'weight' assigned to agents for the purposes of the Build Queue. If you're struggling for overflow build capacity look into setting up an Amazon EC2 account -- though of course you'll incur some recurring costs on that. I wouldn't personally use developer boxes for builds as it would be hard to ensure the integrity (and reliability) of the underlying environment. Chasing (false) build failures due to environment issues is not fun.

comments: author: Cameron Ferguson
body: We are not allowed to push our stuff to external servers outside of our company. So we will figure out a solution for that.

As for the agent-specific capabilities I was already aware of the link you provided, but that isn't what I was looking for. I was looking for agent based variables. We used some inline scripts with our builds. For the example I originally gave let me explain further. For instance with the "make" command i can specify "make -j8" to do 8 cpu processes of the compilation. if I did "-j4" then it'd be 4 jobs. It'd be nice if I could do something like

make ${bamboo.agent.max_jobs}

where that variable could be defined differently for each agent. So for Agent A, the variable could be defined to 4, and with Agent C I could define 8.

Now I know I could easily configure each agent with some environmental variables that are always set and just use those for what I needed, but I was just looking for a Bamboo solution for this.


author: Cameron Ferguson
body: Suprisingly I did find a JIRA task that also talked about agent based priorities:

<https://jira.atlassian.com/browse/BAM-3124> - it's really old though. I went ahead and voted on it