Budowanie projektu cmdline w TeamCity

TeamCity umożliwia uruchamianie buildów za pomocą wielu różnych narzędzi, m.in. MSBuild, nAnt czy Rake. Ja jednak postanowiłem kontynuować swoją, rozpoczętą kilka miesięcy temu, przygodę z FAKE – F# Make. Wcześniej pracowało mi się z tym narzędziem bardzo przyjemnie i odświeżenie znajomości tym razem nie zaszkodzi (a może i wyniknie z tego jakiś post:) ).

Dziwnym nie jest, że "out of the box" TC nie wspiera FAKE, jest to w końcu projekt raczej niszowy. Jedyne wyjście to wskazanie własnego skryptu Build.bat (czy jakkolwiek go nazwiemy) jako pierwszego kroku kompilacji.
[powrót z przyszłości, tzn kwadrans po napisaniu tego zdania: wszedłem właśnie na blog autora FAKE i okazało się, że proponuje on inny sposób uruchamiania FAKE z TC… ale to jest bez znaczenia, ponieważ to nie integracja TC z FAKE nie jest tematem tego posta]

Zapominając zatem na razie o F# i tematach pochodnych, zastanówmy się jakie dane mogą nam być potrzebne podczas buildu. Mi do głowy przychodzą momentalnie dwie informacje: wersja (czyli nr builda nadany przez TC, do nadania jej utworzonym podczas kompilacji assemblies) -  oraz bezwzględną ścieżkę do folderu, w którym wykonuje się build na serwerze (gdybym chciał użyć jakichś dodatkowych narzędzi zawartych w repo).

Wybrałem te konkretne informacje nie bez przyczyny: dostęp do nich uzyskujemy w zupełnie różny sposób. Ale zaraz przekonamy się o tym w praktyce.

Po utworzeniu projektu zostajemy przeniesieni na ekran jego właściwości. Tam możemy zdefiniować między innymi format numerowania buildów:

Zaznaczone pole oznacza, że nasz projekt otrzyma numer wersji 1.0.0 wraz z końcówką zwiększaną o 1 przez TC za każdym buildem. Cały ten numer dostajemy "gratis" jako zmienną środowiskową podczas buildu. Tak przynajmniej obiecuje nam dokumentacja dostępna pod adresem http://confluence.jetbrains.net/display/TCD5/Predefined+Properties#PredefinedProperties-buildNumber. Wynika z tego, że żadna dodatkowa akcja z naszej strony nie jest wymagana.

Nadszedł czas na odpowiednią konfigurację "build runnera", podając wspomniany wcześniej skrypt Build.bat (w głównym katalogu repozytorium) jako punkt startowy całej akcji:

Na stronie konfiguracji integracji z systemem kontroli wersji definiujemy źródłowe repozytorium Gita. Pisałem o tym trochę ostatnim razem.

Wymuszenie buildu po każdym commicie uzyskamy definiując odpowiedni "build trigger":

Do źródłowego repozytorium możemy teraz dodać Build.bat z zawartością:

echo build number: %BUILD_NUMBER%

i puścić commit (+ ew. push, jeśli TC podpięliśmy do zdalnej lokalizacji a nie bezpośrednio lokalnego repo). To pozwoli nam sprawdzić, czy faktycznie numer builda pojawia się sam z siebie w zmiennych środowiskowych.

Za kilka chwil na stronie projektu automatycznie (częstotliwość sprawdzania zmian w repo przez TC ustawia się na ekranie "Edit VCS Root") powinien pojawić się pierwszy build, wraz z opcją przejścia go logów:

A w logach sprytnie zauważymy:

Jea, działa!

Teraz druga informacja, która różni się od numeru buildu tym, że NIE JEST domyślnie przekazywana jako zmienna środowiskowa i trzeba ją sobie zdefiniować ręcznie.

Po pierwsze – wracamy do konfiguracji builda, konkretne do kroku "6: Properties and Environment Variables":

Od razu można chyba domyślić się co trzeba zrobić – w sekcji "Environment Variables" wystarczy kliknąć "Add new variable", wybrać interesującą nas wartość i nadać jej nazwę:

Po tej czynności przechodzimy do "3: Build runner configuration" i po prostu wpisujemy referencję do nowo zdefiniowanej zmiennej (z przedrostkiem "env") w pole parametrów:

Do Buid.bat dopisujemy linijkę:

echo build directory: %BUILD_DIR%

, puszczamy zmiany do repo i czekamy aż kolejny buld pojawi się na stronie projektu (można wymusić pobranie zmian ręcznie, żeby nie czekać zbyt długo).

Sprawdzamy log, a tam:

Dumni ze swoich osiągnięć możemy odpalić Pall Malla. Another mystery solved!