fbpx
devstyle.pl - Blog dla każdego programisty
devstyle.pl - Blog dla każdego programisty
5 minut

Budowanie projektu cmdline w TeamCity


17.11.2010

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:

build-config-general

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:

buildrunner-config

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":

vcs-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:

log1

A w logach sprytnie zauważymy:

log-message1

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":

config-steps

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ę:

add-env-var

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:

pass-env-var

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:

log2

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

Nie przegap kolejnych postów!

Dołącz do ponad 9000 programistów w devstyle newsletter!

Zapisując się na newsletter zgadzasz się na przetwarzanie Twoich danych osobowych w celu wysyłania na wskazany przez Ciebie adres e-mail informacji handlowych o nowościach, promocjach, produktach i usługach związanych z serwisem devstyle.pl. Będzie to marketing bezpośredni, do realizacji którego wykorzystam Twoje telekomunikacyjne urządzenia końcowe. Administratorem Twoich danych osobowych będzie Maciej Aniserowicz prowadzący działalność gospodarczą w Białymstoku (15-215) przy ul. Konopnickiej 14/8, NIP 5422824401. Przysługuje Tobie prawo do cofnięcia zgody, żądania wglądu do Twoich danych, wniesienia sprzeciwu co do ich przetwarzania, sprostowania, usunięcia i ograniczenia przetwarzania. Więcej informacji o tym jak przetwarzam Twoje dane znajdziesz na devstyle.pl/RODO. Powered by ConvertKit
Notify of
maku
maku

TeamCity posiada wiele predefiniowanych zmiennych środowiskowych, w tym również zmienne Build Agent:
teamcity.build.checkoutDir, teamcity.build.workingDir, ….
http://confluence.jetbrains.net/display/TCD5/Predefined+Properties
Nie ma potrzeby definiowania własnego build_dir

procent

@maku:
Dzięki, obawiałem się że to już gdzieś jest:). Chodziło o pokazanie mechanizmu definiowania własnych env vars, i w sumie nie miało znaczenia co dokładnie uda mi się w ten sposób przekazać.

Kurs Gita

Zaawansowany frontend

Szkolenie z Testów

Szkolenie z baz danych

Facebook

Książka

Zobacz również