Pięknego niepodległego wieczora zainstalowałem sobie TeamCity – bardzo przyjemny serwer Continuous Integration od Jetbrains (w dodatku do moich potrzeb – całkowicie darmowy!). Od półtora roku używam go (z wielką satysfakcją) jako dev, ale nie miałem jeszcze wcześniej przyjemności zagłębić się w jego konfigurację i administrowanie. Generalnie: polecam. Chciałem pisać specjalnego posta o instalacji i konfiguracji TC, ale okazało się że za bardzo nie ma o czym. Z poziomu strony WWW bardzo czytelnie można wszystko poustawiać i raczej nikt nie powinien mieć z tym problemu.
Schody natomiast zaczęły się, gdy zachciało mi się potestować współpracę na linii TC-Git. Do testów odpaliłem drugą wirtualkę, założyłem na niej repozytorium, udostępniłem po file-share i chciałem dobrać się niego z poziomu TC. Niestety przez bardzo długi czas nie znalazłem na to sposobu. Plugin odpowiedzialny za komunikację z Gitem (link – ale i tak jest instalowany domyślnie) nie jest chyba w 100% dopracowany, tak jak i dokumentacja do niego. Początkowo nie pomogło nawet mapowanie share na dysk sieciowy… System wyrzucał mi jakieś dziwne błędy nie mające nic wspólnego z rzeczywistością, udało mi się też zawiesić przeglądarkę przez próbowanie najróżniejszych ustawień. Koniec końców zaczęło śmigać, gdy uruchomiłem TC na swoim koncie lokalnym a nie jako domyślny użytkownik "hostujący" usługi (należy mi się w tym momencie blacha w czoło – co prawda komunikaty błędów były mylne, ale i tak powinienem domyślić się w ciągu kilku minut co jest nie tak).
Docelowo jednak nie będę przecież uruchamiał TeamCity na swojej maszynie tylko po to, aby ciągnąć kod z innej lokalnej maszyny – trochę by to było bez sensu:). Planuję raczej odpalić w tle dedykowaną wirtualkę, aby mieliła moje projekty hostowane na Vipserv (o którym pisałem już wcześniej). Postanowiłem zatem przetestować i ten scenariusz. Myślałem że zajmie mi to max kwadrans, a zajęło… lepiej nie mówić.
Coby nie przedłużać: oto konfiguracja która w końcu mi działa:
Po wybraniu "Git (JetBrains)" z list "Type of VCS" czeka nas najgorsze pole z najbardziej irytującymi błędami. Zylion razy widziałem błędy takie jak "java.net.UnknownHostException: ssh", "Invalid URL syntax", "The authentication method ANONYMOUS is not supported for SSH" etc. Chodzi o Fetch URL. Po bardzo wielu próbach okazało się, że działająca konfiguracja to: procentpost_testrepo@procentpost.vipserv.org:testrepo, czyli wg schematu: [vipserv_username]@[domain]:[repo_name]. Olaboga, ileż mnie kosztowało znalezienie tej, wydawałoby się – banalnej, formułki. Kolejny URL zostawiam pusty, ponieważ zmiany wprowadzane przez TC chcę otrzymać do tego samego repozytorium.
Kilka następnych pól to bla, bla, bla, każdy będzie wiedział o co chodzi. Wypada zatrzymać się przy Authentication Method. Dla SSH, z którego korzystamy, potrzebny jest oczywiście klucz. Początkowo wybrałem opcję "Default Private Key" zakładając, że TC weźmie sobie po prostu klucz z katalogu [User]/.ssh. Komentarz pod polem "Uses mapping specified in the file C:\.ssh\config" jakoś mi umknął… ale szczerze mówiąc i tak niewiele mi mówi. Jaki config, jakie mapowanie, o co ci chodzi, ty durny robocie?? Mam swój klucz w /.ssh i stamtąd go bierz! Rozwiązaniem okazała się opcja "Private key", która umożliwia podanie ścieżki do pliku z kluczem prywatnym (uwaga: chodzi o id_rsa, a nie id_rsa.pub!).
No i fajnie, nareszcie zielony komunikat "Connection successful!". Jak miło.
Bonus: w ustawieniach konkretnej już konfiguracji builda polecam w zakładce "Version Control Settings" przyjrzeć się sekcji "VCS Labeling". Dzięki odpowiednim ustawieniom TeamCity będzie nadawać tagi budowanym commitom i wysyłać je z powrotem do repozytorium. Dla przykładu, tagowanie commitów numerami wersji umożliwia to natychmiastową identyfikację buildu w repo, co jest niezastąpione gdy dostajemy zgłoszenie błędu z nr wersji. W kilka sekund możemy mieć na swojej maszynie dokładną kopię kodu, która dany błąd generuje. Przykładowo wpisanie w pole "Labeling pattern" wartości "tcbuild-%system.build.number%" da nam w repozytorium tagi "tcbuild-1.0.0.45, tcbuild-1.0.0.46" itd (oczywiście możemy dowolnie kontrolować schemat nadawania buildom numerów – ale to już osobna bajka).
To chyba ostatnia czynność potrzebna do porządnie zorganizowanej pracy nad projektami. Mam nadzieję że komuś ta miniseria postów o Vipserv się przydała. Zapewniam, że nie jestem żadnym diabelskim wysłannikiem tej firmy i nie uprawiam nieetycznego lobbingu – jeśli pojawią się jakieś problemy to z pewnością nie omieszkam o nich wspomnieć na blogu:).
