2012-06-19 10 views
6

Narzędzia:
Jenkins ver. 1,470
Maven 2
SubversionJenkins Partial Build/Modular Build na Commit Hook

Środowisko

Załóżmy mój build ma szereg projektów A-D. Wykres zależności istnieje tak, jak pokazano. To znaczy: B zależy od klas w A, C zależy od klas w B, D zależy od klas w A. Tworzymy kompilacje Jnkins w taki sposób, że nazywają one kompilacje zależne od nich jako działanie po wybudowaniu.


| -> B -> C
| -> D

Każdej nocy, możemy wywołać pełną budować w Jenkins (A buduje, wyzwala B (wyzwalacze C), wyzwalacze D). Robi się to dość łatwo, mówiąc A budować co noc, a reszta spływa kaskadami.

Problem

jednak na zatwierdzenie chcemy budować projekty, które zostały popełnione na raz.

  • Sytuacja 1: My odpytywanie repozytorium (lub użyć commit hooks, nie ma znaczenia), a okaże się, że doszło do popełnienia do B, a następnie B i C będą budować zbuduje. Sukces!

  • Sytuacja 2: My odpytywanie repozytorium i okaże się, że B i C zostały popełnione w jeden commit, następnie Jenkins będzie starał się budować B (wyzwalanie kompilacji C) i zbudować C (drugi build). Niepowodzenie. Zobacz, co się dzieje? C został zbudowany dwa razy, zabierając cenny czas budowy. Zachowaj szybką budowę!

Czy ktoś zna sposób, aby tylko wyzwolić najwyższy projekt w każdej zaangażowanej budowy rurociągu?

Przypuszczam jedno rozwiązanie byłoby skomplikowane hak SVN, który określa najwyższy projekt w każdej z nitek rurociągu ...

  • Sytuacja 3: Zobowiązanie do B C i D w jednym popełnić. Wykrywanie haków SVN C zależy od B. Haczyk wywołuje specyficzne dla projektu odsyłacze do uruchamiania kompilacji dla B i D.

Pułapki: bardzo złożony hak commit SVN. Trzeba utrzymywać rurociąg w haku SVN.

Mam wrażenie, że to problem, na który napotykają inni. Czy istnieje wtyczka Jenkins, która pomaga w tym?

+0

W przypadku 2, projekty Jenkins C & B patrzą na ten sam projekt svn? – thekbb

Odpowiedz

1

Byłby to pomysł, aby powiedzieć jenkins, aby czekać z kompilacją, aż kompilacja, która zależy od jest skończona. Jest to flaga w konfiguracji zadania, aby to zrobić. Ale musisz to zrobić dla każdego zadania. Btw ...jest jeszcze inna flaga, która wymaga, aby jenkins czekał z kompilacją, aż zadanie zależności zostanie zakończone.

0

Poszukuję również skutecznego rozwiązania tego problemu. Widziałem kilka sugestii, ale do tej pory udało nam się tylko uniknąć jednej z tych pułapek, serializując kompilację za pomocą wtyczki Locks &. Nie zapobiega to wielokrotnemu budowaniu projektu od pojedynczego sprawdzania, ale gwarantuje, że projekt zostanie odbudowany sekwencyjnie po ukończeniu projektu wyższego szczebla.

To naprawdę skomplikowany problem do rozwiązania w ogólnym przypadku, ale myślałem o napisaniu wtyczki, aby sobie z tym poradzić. Jednym prostym rozwiązaniem jest po prostu sprawdzenie, czy projekt generowany obecnie jest w fazie budowy i usunięcie go z kolejki kompilacji, jeśli tak jest. Ponieważ zadanie upstream uruchomi kompilację po jej ukończeniu, jest to jedna z opcji.

Lepszą opcją byłaby wtyczka automatycznie zarządzająca kolejką kompilacji w oparciu o wykres zależności. Może to być skomplikowane, ponieważ musisz upewnić się, że żadna kompilacja nie zostanie rozpoczęta, dopóki wszystkie jej zależności nie zostaną zakończone. Zasadniczo oznacza to, że każde zaznaczenie spowoduje, że wtyczka automatycznie doda wszystkie kolejne kompilacje do kolejki, aby mogła nimi zarządzać. Możliwe, że jest to sprytny i łatwiejszy sposób, aby to zrobić z istniejącymi wyzwalaczami w górę/w dół, ale nie jest dla mnie jasne, jak to jeszcze zrobić. Istnieją już wtyczki do budowania potoków, które twierdzą, że potrafią poradzić sobie z tą sytuacją, ale wyraźnie nie robią nic, aby zapobiec warunkom wyścigu, w których kolejna kompilacja może zostać uruchomiona przez to samo sprawdzanie, co poprzednia kompilacja.