Build Agent Priority
This suggestion is migrated to Developer Community. Please use below link to view the current status.
We currently have 3 on-prem build machines, with 4 build agents each.
The priority to "grab" agents seems always to be in the order that they were installed (in our case we installed server by server), so if a Build uses 4 Agents, they all get used from the same server.
For us, it would be faster if the build agents that get used for a single build would be spread across servers.
So my suggestion is that you have the ability to set "Agent Priority", so that we can have Build Agent 1 from each server as a Priority 1 Agent, Build Agent 2 from each server as Priority 2 etc.
This way, we could evenly distribute the load to these machines.
VSTS Team, is this being tracked via an issue on the main repo? (https://github.com/Microsoft/azure-pipelines-agent). We'd like to track it and update our private agents as soon as a fix becomes available.
Orion Edwards commented
The biggest reason we want this is to determine which build machine is the "best".
We had the following situation:
- Single big fancy build machine, running for a while, but sometimes it's busy
- Create a secondary smaller build machine as a backup
Now ALL THE BUILDS get queued on the backup.
As a workaround, we removed and re-added the big build machine from the agent pool, but this is a terrible way to manage things.
Simply putting an integer "priority" field in the build agent config screen would easily solve this
Hi all, this is great feedback, I just wanted to let you know that we have made some improvements to the way we handle agent assignment that should at least help prevent the scenario where all of the builds go to the agents on a single build machine despite having idle build machines with no busy agents.
For example, if you had 3 machines (A, B, C) and each has a few agents we will assign the builds to the agents by looking for an available agent on the most idle machine.
I'll leave this item open though since it has plenty of good ideas for giving you more control over the process.
why is this not a thing? I see hunders of build on first agent and 1 on the 3rd... round robin would be great.
or the comment by Wagner makes sense.
James Pennington commented
I'm definitely interested in the priority selection. We have a number of local TFS build agents across multiple computers. Some of these computers have better CPUs / SSDs etc. in them and it would be nice to have the lower end systems be used only if the high end systems are busy. The current process for doing rearranging this is a little painful.
Wagner Cordeiro Janissetti commented
Add features like:
- Priority: define priorities for buildings
- Rotation: after using a build agent put it at the end of the agents list. Use others before this one.
- Random: define settings for random/not random
Erik Medina commented
This would be especially important for private build agents hosted in Azure that use the recently introduced B series VMs with burst metering. The current implementation for agent selection in VSTS heavily favors the first agent that's registered which means the banked CPU credits for that agent's VM will be drained faster than the rest of the VMs in the pool resulting in slower builds due to less time being able to burst to a full CPU load.
Seems that TFS will constantly use the same agent it used for the previous build as its next agent, rather than picking an available agent randomly from the pool.
This is different from TFS2012 for sure.
If I have 48 agents waiting, it will keep using the same one.
This makes it more difficult to get to the workspace of a failed build and investigate it because it can be overwritten in that workspace so fast by the next build.
This is a little frustrating. Also, by not randomizing it, build servers are not exercised properly to expose differences or problems that may arisse.
Add a setting for this "Random/Not-Random"