Dlaczego *** NO_CI *** nadal powoduje ciągłą kompilację intregration?

Question

Niedawno odkryłem "ukrytą funkcję" TFS, która pozwala zapobiec budowaniu CI, jeśli komentarz zawiera ***NO_CI***.

Mam TFS działa w domu, a to działa trochę sztuczki działa jak urok.

W pracy używamy również TFS 2010. Stwierdzam, że to nadal nie zapobiega budowaniu CI od rozpoczęcia w naszym setupie.

Moje pytanie brzmi: jaki proces faktycznie sprawdza, czy w komentarzu znajduje się ***NO_CI***, aby określić, czy blokować kompilację CI? Moją pierwszą myślą było przyjrzenie się szablonowi kompilacji. Nie widziałem niczego zbyt oczywistego. Czy ktoś na to wpadł? Czy możesz wskazać mi właściwy kierunek?

Answer 1

Ten numer okazał się błędem po mojej stronie. Gdy moja kompilacja się powiedzie, otrzymałem kilka automatycznych meldunków. Pierwsza obejmowała ***NO_CI***, a druga nie. Nie zdawałem sobie sprawy, że drugi check-in został przekształcony w ścieżkę, którą druga kompilacja została zmapowana w jego przestrzeni roboczej. Tak więc pierwsze odprawa nie spowodowała rozpoczęcia budowy CI, było to drugie odprawa.

Answer 2

Zasadniczo, gdy dojdzie do sprawdzenia, terminal AT przechwyci i uruchomi zdarzenie, aby powiadomić komponent kompilacji o meldowaniu. Komponent budowania następnie podejmuje odpowiednie działanie według typu wyzwalacza (ciągła integracja, tocząca się kompilacja, zaplanowana kompilacja, bramkowana kontrola itd.) Dotkniętych definicji budowania.

Jeśli komentarze do wpisu zawierają ciąg ***NO_CI***, ale zestawy zmian nadal wyzwalają kompilacje CI, spójrz na dzienniki zdarzeń na terminalach AT i zobacz, czy są jakieś ostrzeżenia z komunikatem "TF215041: Nie można przetworzyć zestawu zmian n ".

Jeśli Twój zespół korzysta z bramkowej definicji budowania czeku, upewnij się, że nie wyłączył on komentarza ***NO_CI*** z szablonu kompilacji, aby zezwolić na bramkowany zestaw zmian checkin do wyzwolenia CI.