I have a TFS 2010 build service installed with three agents: Database, Production, and Release with mutually exclusive sets of builds running on each.
When builds are queued, unfortunately, they appear to get queued in groups of three regardless of which agent they're ready to go to. This means that we lose the parallelism I was hoping for if more than three builds from a single agent are run at once as they will take up the entire queue.
Is there a way to make sure that builds are queued once their own agent becomes free so that we can have as many parallel builds as possible?
Using the TFS 2010 default build defintion you cannot select an build agent but only a build controller unless you have customized it. Ideally you should have a single build controller, which has multiple build agents beneath it. Within the build definition you would only be selecting controller name and the build controller pushes the build to the agent which is free at that point. You can also use TAGS to make sure that the build runs on only a particular build agent.
Related
I have 10 build agents configured in two servers under one agent pool. Whenever the first four agents are used, the build requested is in the queue on the first four agents, but there are another six agents which are available and the builds are not queued to those agents.
It's been almost six months and agent 10 has not even once handled a build. Other agents from 5 to 10 are hardly used. Why is there this phenomenon? How can we handle this by using all the agents fairly?
TFS will auto select the available build agent in the pool when running the build. It's more like a conditional random choice. It's not able to prioritize the build agent for now. There has also been a related uservoice as below:
TFS 2015 build vNext agent prioritization
As a workaround you could specify a build agent in vNext build.
You can add a User Capability to that specific build agent. Then in the build definition you just need put in that capability as a demand (General tab).
It seems like the builds are queued on the 'oldest' agents first. So if agent 10 is the last agent you created, it will only be used if the first 9 are in use, assuming they all have the same capabilities.
It does not appear to be a random selection of agents, but based on the order of creation of agents. Ironically that means that if you add a new powerful build server, those agents will be at the bottom of the queue.
The user voice suggestion in PatrickLu-MSFT's answer is to allow the agent to be prioritized.
The workaround at this moment seems to be to remove all (or some) agents and re-create them in the order you want them to be used. Which still means the last agent will be used less, but at least you can influence the distribution of the agents a bit.
We are running into this issue as well. We have six build servers with three agents each and builds are not distributed fairly. I also do not want to assign an agent per definition, but I guess we are going to have to puzzle with it.
We are using TFS and the TFS Build Service. We are considering to migrate the Build service to Jenkins but we came across some issues. According to this site, there are some things that do not work very well with the TFS and Jenkins plugins. All of them we use a lot:
Associated Change sets – Team Build automatically associates a list of change sets that are included in the build
Associated Work Items – Team Build analysis the relationships and also associates Work Items with a build. Indeed it walks the work item tree (parent) and maintains that association in the chain.
Is this still true? We have this scenario:
A developer checks in a code that fix a bug or resolve a User Story. It does that by associating his check in with the work item ID.
His check in triggers a build that will associate the work item with his changeset. For bugs, the build will update the "Integrated in Build" field with the build number. We use this field to know in witch version the bug was fixed.
Is there any way to make Jenkins behave and do what TFS build service does?
Another option is to mix the two using dummy builds on the TFS side that set the records straight and kick-off the Jenkins' builds. Some hints
How to trigger Jenkins builds remotely and to pass parameters and “Fake” a TFS Build.
This approach requires a bit of effort but has many advantages:
No big-bang, use Jenkins opportunistically
Can continue using existing builds
Having a build identifier in TFS allows you an overall monitoring and to use the Test features
I have a VSTS build definition for one of our projects that requires jenkins to build, but we still have all our other products using VSTS natively. To maintain consistency, this build definition triggers a jenkins build. We configured the build definition to not sync code as jenkins will download it (save time) and not to publish the artifacts back to the agent (i have another script for that found here). This allows developers to continue to use git as normal, and the build/release process is consistent with our other products. Along with task tracking and such.
My company has a bunch of different builds and half a dozen different build agents, and I need to update some software for one of the builds. I don't want to break any other builds that are using said agent. I would like to get a list of all builds that use said agent so that I can validate them after my software updates on the agent. I would prefer not to individually review each build, as there are dozens, if not hundreds of them. Is there some way to get this information quickly? Either from the agent, or from TFS somehow?
By default, builds are tied to controllers, not agents and could therefore run on any of the agents bound to the controller. Unless as suggested by Daniel Mann, you have your builds tagged to specific agents you won't be able to get that level of detail. Without tagging, your report would be limited to a list of machines that each build could possibly run on.
What I do in this situation is to have a separate, private build controller for build software testing. Upgrade the software on this and then queue test builds for the affected definitions, changing the controller to your test controller in the Queue Build parameters. Once you've verified that your changes won't break the builds you can then schedule downtime to upgrade the production agent machines.
I am using TFS 2010 and have a build machine that contains a single build controller running 2 agents.
I have worked out that I can assign a tag of "Nightly" to my 2nd agent and then edit the Build Definition for my Nightly Builds in TFS to only use an agent that has the tag of "Nightly".
Easy enough.
However, the issue here is that if a normal build (Such as dev/CI) came along, it could - in theory- use my nightly agent, which I don't want to happen.
I could go around all our development builds (20+) and add in a tags=normal and tag my primary build agent with normal, but this then relies on people remembering to tag up new builds in the future.
Is there a way to set up my build agent in TFS's Server Admin, so that it will ONLY run items with specific tags? Or is my "go around the houses" approach the only logical way?
Edit
I got around this in the end by making all my builds look for "matchExactly" on empty tags, which means my "nightly" tagged agent will never be used for CI.
I believe the default for build definitions says MatchExactly and has an empty Tags Filter field. This means that by default build definitions will only run on Build Agents that have ZERO tags. So the behavior you desire should be the default, when you tag your build agent with the Nightly tag, no builds will run on that agent unless somebody explicitly goes in and changes the default Agent settings for that build def.
I expect that this agent is already running on it's own server, otherwise there'd be no reason to single it out.
You could give this specific build agent it's own build controller, that way chances of a build associated to the "CI" build controller are zero. unless people chose the incorrect Build Controller for their build definition.
This way you also won't have to go about changing the current build definitions.
We have two TFS build servers (build controllers) available for our application. Builds are triggered as configured in the build definition. Every build is configured via "Build Defaults" page to specific build controller.
Let's say we have a gated check-in build. Build time is 30 minutes, 3 check-ins are made per hour. Normally these 3 gated check-in builds are triggered on the build controller 1, other build controller2 is idle.
How to trigger gated check-in build on the build controller2 if build controller1 is in use?
Is it possible to queue build on the build server with shortest build queue?
How to configure load balancing on build controllers?
EDIT:
I found possible solution for TFS2008 here. I'm looking for solution working for TFS2010
I don't think this is possible. A controller can balance a build out onto which ever agents are available and that match the agent pattern of the the build (as defined in the build definition). Unless you have a serious load of build's, I would stick with a single controller per collection and more agents.
The controller does very little work compared to and agent (which does the compilation, testing and deployment).
For your cases I would try something like:
Controller
Gated Agent 1 (on \\sv-BuildAgent1)
Gated Agent 2 (on \\sv-BuildAgent2)
QA Agent... (on \\sv-BuildAgent3)
Other agents... (on \\wherever)
...etc...
Now each of the Gated Build's Definition you would set the Build Agent to "Gated Agent *" (It's under the Process tab in 3. Advanced -> Agent Settings -> Name Filter.). This will now pick any agent that starts with "Gated Agent". You can easily scale this to as many agents on as many boxes as you need.
EDIT:
You can also put Tags on Build Agent to a achieve a similar result. This may be easier to configure. You Define the Tags in the Build Agent's properties and Configure Definitions to use them in the same section as the Name Filter (above).