Czy można uzyskać dwie wersje do kasy w tym samym katalogu i jak to zrobić?TeamCity dwie kompilacje przy użyciu tego samego katalogu kasowego
Obecnie dwie różne kompilacje sprawdzają się w dwóch różnych katalogach.
Możesz tego dokonać, przejmując kontrolę nad lokalizacjami katalogów kasy.
Najpierw musisz zdefiniować swój katalog kasowy na coś, co może być znane obu kompilacjom. W konfiguracji kompilacji przejdź do Ustawienia kontroli wersji -> Ustawienia transakcji. Zmień ustawienie katalogu usługi Checkout na Custom Path. Zostaniesz poproszony o podanie katalogu, do którego chcesz wysłać swoje źródło. Może być w dowolnym miejscu **, o ile TeamCity ma tam uprawnienia do zapisu.
Następnie trzeba zmodyfikować reguły Checkout (również od ustawień kontroli wersji) dla każdego projektu tak, że są one kierowania folder względem korzenia Checkout Directory. Możesz to zrobić, ustawiając regułę na +:%some.repo.path%=>/%some.sub.folder%. Możesz przepisać dowolny podfolder, który tam chcesz. Po prostu kasujemy wszystko do katalogu głównego katalogu Checkout (=>/).
Jeśli oba projekty są przedstawieniu tego samego Kasa Directory, wtedy ta kombinacja ustawienie powinno daje kontrolę i elastyczność, które szukasz.
** Dla naszego katalogu Checkout używamy wartości parametryczne %teamcity.agent.work.dir%\%system.teamcity.projectName%\%branch%. Pierwsze dwa parametry są parametrami systemu TeamCity, a ostatni jest przez nas zdefiniowany. W naszym systemie jest to G: \ BuildAgent \ work \ $ PROJECT \ $ BRANCH, dzięki czemu wszystko jest uporządkowane i przewidywalne.
Wydaje ustawienia VCS (zestaw VCS korzeni i zasad Checkout) są różne dla nich budować konfiguracje, i to jest powód dlaczego TeamCity wykorzystuje inny katalog realizacji transakcji. W takich okolicznościach nie zalecałbym, aby serwer korzystał z tego samego katalogu.
Załóżmy, że masz dwie konfiguracje A i B oraz skonfigurowano TeamCity zbudować je w tym samym katalogu, ale A i B mają różne ustawienia VCS. Co należy wtedy zrobić podczas realizacji transakcji?
Na przykład, kiedy kończy budować na środek i budować B rozpoczyna się w tym samym środkiem, TeamCity będzie musiał oczyścić wszystkie źródła w katalogu kasy i pobrać je ponownie. Ta sama historia ma miejsce, gdy kompilacja B rozpoczyna się po kompilacji A. W rezultacie te czyste kasacje spowodują spowolnienie.
Z automatycznie wygenerowanym katalogiem kasowym serwer może zoptymalizować wydajność kasowania i wykorzystanie dysku przez agentów. Podejście z niestandardowym katalogiem realizacji transakcji nie jest optymalne i nie jest skalowalne. Unikaj go, jeśli to możliwe.
Zobacz także: http://confluence.jetbrains.com/display/TCD8/Build+Checkout+Directory http://confluence.jetbrains.com/display/TCD8/Clean+Checkout