2016-05-09 11 views
0

Wir bewegen uns zu einem monolithischen Repository für ein Projekt, was bedeutet, dass wir bei einem Commit auf der Team-Stadt bestimmen müssen, welcher Build gestartet werden soll.Teamcity - Überwachung eines bestimmten Ordners als VCS-Trigger

Betrachten Sie das folgende Repo:

/ 
    a/ 
    b/ 

Wir derzeit baut pro Teilprojekt, die ausgelöst werden müssen, wenn

begeht In VCS löst, können wir eine VCS-Trigger-Regel erstellen, die "scheint" jedoch zu arbeiten ich habe folgende Fragen:

  1. wenn ich eine Änderung begehen b in Ordnern, durch eine Trigger-Regel kann ich nur die Builds für b Anstoß. Die Builds für a zeigen jedoch ausstehende Änderungen, die nicht verwandt sind.
  2. Ist dieser Ansatz langfristig sinnvoll? Gibt es unbeabsichtigte Fehler, die auftreten?

Antwort

2

Ich glaube nicht. Wenn Sie Trigger-Regeln im VCS-Trigger verwenden, bedeutet dies nur, ob ein Build automatisch gestartet wird, wenn etwas eingecheckt ist. Also ja, die ausstehenden Änderungen werden natürlich angezeigt und wenn Sie eine Abhängigkeit von einer Build-Konfiguration zu einer anderen haben wird ein neuer Build ausgelöst, auch wenn nur "nicht zusammenhängende" Änderungen vorliegen. Aber ich denke nicht, dass Sie irgendwelche Nachteile haben werden.

+0

Ich fühle, dass die "schwebende Änderung" ein Nachteil sein wird, wie jeder, der es sieht, als ob etwas Verwandtes nicht gebaut hat. Im Laufe eines Projekts wird diese Zahl groß sein. –

+0

Nun, Sie könnten einen zusätzlichen Nightly-Trigger einrichten, so dass zumindest nachts die Projekte erstellt werden und die Anzahl der ausstehenden Änderungen niedrig bleibt. – Vampire

+0

Einverstanden, macht Sinn. –

3

Wenn Sie nicht zusammenhängende ausstehende Änderungen anzeigen möchten, sollten Sie die Auscheckregeln verwenden. Wenn Sie Auscheckregeln auf + setzen, zeigt ein TeamCity nur Änderungen unter "a" an. Beachten Sie jedoch, dass bei solchen Ausgaberegeln nur das Verzeichnis "a" im Checkout-Verzeichnis des Agenten angezeigt wird.