Jak skonfigurować TeamCity do obsługi modelu GitHub pull-request dla integracji kodu źródłowego?

Question

Używamy TeamCity i GitHub Enterprise. Używamy obieg open-source-owskiej z git: istnieje mainline repozytorium dla każdego komponentu, a kiedy ludzie chcą wprowadzić zmiany, one

• widelec mainline na własny rachunek (więc nie może być wiele widelce)
• utworzyć oddział w ich rozwidleniu
• wdrażania zmian
• przynieść na bieżąco z mainline/master zmian, które miały miejsce w międzyczasie
• złożyć wniosek odrywanie fork/feature-branch ->mainline/master

Jesteśmy bardzo zadowoleni z tego przepływu pracy; wymusza przegląd kodu (no, co najmniej krok ręczny, który, mam nadzieję, wymaga odczytywania kodu i przeprowadzania testów) zanim linia główna zauważy jakiekolwiek zmiany, które historycznie stanowiły problem. Chcielibyśmy użyć interfejsu GH Status API (blog post, API doc), aby włączyć przycisk scalania w kolorze innym niż zielony, jeśli autor jest osobą przeglądającą żądanie pobrania, ale to na później.

Mamy TeamCity 7.1 skonfigurowany do oglądania głównych repozytoriów i budować, gdy zmiany są widoczne. Jednak sposób, w jaki jest obecnie skonfigurowany, CI buduje tylko wtedy, gdy widzi zmiany na mainline/master.

Jak powinniśmy skonfigurować nasze korzenie VCS w TeamCity, abyśmy mogli mieć ten sam przepływ pracy, ale CI uruchomi kompilację opartą na gałęziach w widłach głównego repo? Najlepiej bez konieczności rejestracji każdego widelca osobno?

Czytałem dokumentację TeamCity 7.1 jest funkcja-Branch (blog post, release notes, documentation), ale nie widzę, jak zastosować je do naszego modelu arbitralnej-number-of-widelców, w przeciwieństwie do everyone- zatwierdza do głównych linii w oddziałach.

Answer 1

Można monitorować pull-żądań przez TeamCity: http://blog.jetbrains.com/teamcity/2013/02/automatically-building-pull-requests-from-github-with-teamcity/

Answer 2

Według mojej wiedzy TeamCity nie będzie "wyszukiwać" twoich widelców github w żaden zautomatyzowany sposób.

Rozwiążę to, tworząc katalog główny vcs dla każdego rozwidlonego repozytorium programisty oraz główne repozytorium. Następnie dołącz każdy z tych katalogów do kompilacji. Docs.

Niestety jest to proces ręczny. Raz na programistę, repo na komponent. Jeśli naprawdę chciałbym to zautomatyzować, przyjrzałbym się kombinacji Github Hooks i adding vcs roots via the TeamCity REST Api.