Frage

Wir haben ein TFS2010 -Setup mit einem einzelnen Controller und 2 Agenten, die auf demselben Build -Computer ausgeführt werden. Gestern hat der Build -Server keine gleichzeitigen Builds ausführen und ließ nur einen Agenten die Arbeit erledigen. Ich habe versucht, den Controller und die Agenten neu zu starten, aber ohne Schloss. Es gibt kein Muster und beide Agenten arbeiten - nur eins nach dem anderen. Ich habe heute einen neuen Agenten hinzugefügt (gleiche Maschine) und es kann jetzt 2 gleichzeitige Builds aufnehmen - immer noch einen faulen Agenten. Irgendwelche Gedanken?

Neue Infos: Wenn ich 2 laufende Builds und ein Paar in der Warteschlange habe (NB mit insgesamt 3 Agenten) und ich ändere die Priorität auf Hoch - es baut auf dem letzten Agenten auf!?

War es hilfreich?

Lösung

OK - Ein ungültiger Eintrag in TBL_BUILDQUEUE in der TFS -Datenbank war der Grund.Normale Prioritätsbaute werden in TFS 2010 nicht aufbauen

Quick Fix besteht darin, die Einträge in TBL_BUILDQUEUELE zu löschen, die eine nicht existierende Definition haben.

SELECT * FROM [Tfs_Default].[dbo].[tbl_BuildQueue] where DefinitionId not in (select DefinitionId from tbl_BuildDefinition)

Andere Tipps

Es gibt ein paar Dinge, die Sie überprüfen können:

  • Sind eine der Build -Definitionen für verwendete Agenten -Tags oder Agentenname -Filter konfiguriert?
  • Sind einer der Agenten mit Tags konfiguriert? Sie können die TF -Administratorkonsole einchecken.
  • Überprüfen Sie den Status jedes Agenten mit "Build" -> "Build Controller verwalten ..." von Visual Studio.
  • Überprüfen Sie den Status jedes Agenten mithilfe der TF -Administratorkonsole auf dem Agenten.
  • Meldet die TF -Administratorkonsole in den letzten 24 Stunden Ereignisse?

Derzeit arbeiten wir mit einem Kunden zusammen, um ein Problem zu lösen, das Agenten zu einem Build, der nicht mehr ausgeführt wird, verwaiste. Dies geschieht aufgrund einer Rennbedingung in einem gespeicherten Verfahren und hat nichts mit fehlenden ausländischen Schlüsselbeziehungen zu tun.

Wenn Sie überprüfen möchten, ob dies tatsächlich aufgetreten ist, führen Sie die folgende Abfrage in Ihrer Projektabläufdatenbank aus:

   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

Wenn dies Zeilen zurückgibt, können Sie das Problem vorübergehend beheben, indem Sie die Spalte "ReservationID" die betroffenen Build -Agenten wieder auf Null festlegen. Nach der Aktualisierung dieser Spalte kann jede neue Builds nach dem Update in der Warteschlange in die Warteschlange gestalten, die den Agenten verwenden können, der zuvor "faul" war, wie Sie es ausdrückten.

Patrick

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top