Continuous integration dla wielu folderów

0

Nie do końca wiedziałem jak nazwać temat dlatego przejdę od razu do sedna. Mam repo SVN w którym mam następującą hierarchię

svn://adres/trunk/folder1
svn://adres/trunk/folder2

dla uproszczenia załóżmy, że interesuje nas tylko folder 1. Mam w nim kilka folderów m.in.

/folder1/binaries/
/folder1/cos1/
/folder1/cos2/
/folder1/plugins/
/folder1/source/
/folder1/plik1

z tego wszystkiego interesują nas tylko foldery binaries, source i plugins oraz plik plik1. Folder plugins wygląda analogicznie jak folder1, ma foldery binaries, source i inne nieistotne.

I teraz chcę mieć następująca sytuację, commitować można tylko do folderów source, co jakiś czas chcę aby system CI robił:
update na folderach source, jeżeli sa jakieś zmiany to
revert na plikach z konkretnym rozszerzeniem
zbudował mi wszystko używając do tego gotowego skryptu
po udanym buildzie zrobił commit do repo.

Z tego co czytałem najbardziej polecane do tego narzędzia to Jenkins lub TeamCity, ja nigdy nie miałem doświadczenia z konfigurowaniem któregokolwiek z tych narzędzi, próbowałem coś sam zrobić ale doszedłem tylko do tego, że zarówno Jenkins jak i TeamCity updatowały mi całe repo do swojego workspace'a (a tego chcę uniknąć bo w nieistotnych folderach są pliki binarne które sporo ważą). Jeżeli ktoś mi pomoże w ogarnięciu tego będę bardzo wdzięczny.

0

A czemu trzymasz niepotrzebne do buildowania pliki w repozytorium?

0

Ponieważ nie tylko programiści z niego korzystają.

Może żeby trochę rozjaśnić, tworzymy grę w Unreal Engine 4, co oznacza, że w repozytorium musimy mieć skompilowany kod źródłowy gry i silnika, blueprinty ze skryptami (które niestety też są plikami binarnymi) oraz masę innych plików które muszą być w jednym miejscu (animacje, modele, tekstury, muzyka itp.). Dotychczas każdy z programistów po prostu razem ze wrzucaniem kodu wrzucał tez skompilowane u siebie binarki, ale teraz chcieliśmy to trochę zautomatyzować i mieć oddzielny komputer do cookowania i buildowania. Mamy już napisany skrypt .bat który w zasadzie robi to co napisałem z tym, że nie jest to automatyczne, nie dość, że trzeba go odpalić ręcznie, to jeszcze trzeba po skończonej kompilacji ręcznie zaakceptować commita (i zdarzało się już kilka razy, że ktoś po prostu zapomniał scommitować co powodowało różne błędy).

0

A nie możecie mieć jednego repozytorium na kod (i to podpiąć pod TeamCity), a drugiego na zasoby?

0

Jest to jeden z pomysłów które mieliśmy, ale to wprowadziłoby pewnie trochę zamieszania, a mój szef chce mieć wszystko w jednym miejscu, trzeba by to było jakoś synchronizować żeby inni devowie mieli dostęp do aktualnych binarek itd. Ogólnie trzymam to jako zapasowy pomysł, jeżeli się nie uda zrobić tego co opisałem w pierwszym poście to będzie to pewnie jedyne, sensowne rozwiązanie.

0

Jeśli dobrze pamiętam to w SVN możesz wyciągać konkretne foldery więc jako "coś" do budowania podajesz ten folder a nie "root" repozytorium. Dodatkowo w Jenkinsie jako krok zadania budującego możesz dodać uruchomienie skryptu. Więc będąc już w bashu możesz z tym zrobić co tylko dusza zapragnie :)

1 użytkowników online, w tym zalogowanych: 0, gości: 1