0

We have a TFS2010 setup with a single controller and 2 agents running on the same build machine. Yesterday the build server stopped running 2 concurrent builds and just let one agent do the work. I've tried to restart the controller and agents but with no lock. There's no pattern and both agents are doing work - just one at a time. I've added a new agent today (same machine) and it can now pick up 2 concurrent builds - still got one lazy agent. Any thoughts?

New Info: When I have 2 running builds and a couple in the queue (NB with 3 agents in total) and I change the priority to high - it starts to build on the last agent!?

jaspernygaard
  • 3,098
  • 5
  • 35
  • 52

3 Answers3

2

Ok - so an invalid entry in tbl_BuildQueue in the TFS database was the reason. Normal Priority Builds Will Not Build in TFS 2010

Quick fix is to delete the entries in tbl_BuildQueue which have a DefinitionId that doesn't exist.

SELECT * FROM [Tfs_Default].[dbo].[tbl_BuildQueue] where DefinitionId not in (select DefinitionId from tbl_BuildDefinition)
Community
  • 1
  • 1
jaspernygaard
  • 3,098
  • 5
  • 35
  • 52
0

There are a few things you can check:

  • Are any of the Build Definitions configured to used Agent Tags or Agent Name Filters?
  • Are any of the Agents Configured with Tags? You can check in TF Admin Console.
  • Check the status of each agent using "Build" -> "Manage Build Controllers..." from Visual Studio.
  • Check the status of each agent using TF Admin Console on the agent.
  • Is the TF Admin Console reporting any Events in the last 24 hrs?
DaveShaw
  • 52,123
  • 16
  • 112
  • 141
  • Builds are not configured to using tags and none of the agents have any tags. Status for both controller and agents seem fine - Number of concurrent builds for the controller is set to the number of agents registered. Only events in the log, are restart events (Controller and agents) – jaspernygaard Feb 17 '12 at 09:42
0

We are currently working with a customer to resolve an issue that can leave agents orphaned to a build which is no longer running. This occurs due to a race condition in a stored procedure and has nothing to do with missing foreign key relationships.

If you would like to verify that this has in fact occurred, run the following query on your project collection database:

   SELECT  * 
   FROM    tbl_BuildAgent ba 
   LEFT JOIN tbl_BuildAgentReservation bar 
   ON      bar.ReservationId = ba.ReservationId 
   WHERE   ba.ReservationId IS NOT NULL 
           AND bar.ReservationId IS NULL

If this returns any rows, you can temporarily fix the issue by setting the 'ReservationId' column the affected build agents back to NULL. After updating this column any new builds queued after the update will be able to utilize the agent which was previously "lazy" as you put it.

Patrick

Patrick Carnahan
  • 11
  • 1