Podmoduły Git nie aktualizują się w kompilacji Jenkinsa

85

Mam podmoduł w projekcie w Jenkins. Włączyłem zaawansowane ustawienie rekurencyjnej aktualizacji modułów podrzędnych.

Gdy uruchamiam kompilację, widzę, że obszar roboczy zawiera pliki z modułu podrzędnego. Problem w tym, że wydaje się, że jest to pierwsza wersja podmodułu. Kiedy wypycham zmiany (repozytorium hostowane na GitHub), Jenkins nie wydaje się aktualizować modułu podrzędnego, aby uzyskać odpowiednie zmiany. Czy ktoś to widział?

git jenkins git-submodules

— Ben
źródło

96

Zwróć uwagę, że wtyczka Jenkins Git 2.0 będzie miała „zaawansowane zachowania modułów podrzędnych”, które powinny zapewnić prawidłowe aktualizacje modułów podrzędnych:

Jak skomentował przez vikramvi:

Advanced sub-modules behavior> „ Path of the reference repo to use during submodule update” w tym polu dodaj adres URL git modułu podrzędnego.

Owen B wspomina w komentarzach :

W przypadku problemu z uwierzytelnianiem dostępna jest teraz opcja „Użyj poświadczeń z domyślnego zdalnego repozytorium nadrzędnego”

Widziane tutaj w JENKINS-20941 :

— VonC
źródło

6

Ale jak? Czy możesz podać szczegółowe instrukcje, które opcje wybrać? Dzięki.

— zavié

8

@ zavié Myślę, że powinieneś wybrać "Zachowanie zaawansowanych podmodułów", a następnie zaznaczyć pole wyboru "Aktualizuj podmoduły rekurencyjnie", które się pojawi, i kliknij Zapisz.

— KajMagnus

9

To nie działa, jeśli używasz prywatnego repozytorium.

— Erik

1

— Udało

3

Działa to tylko wtedy, gdy repozytorium nie wymaga uwierzytelniania do odczytu modułu podrzędnego git. Błąd Jenkinsa.

— Ernst Kuschke

33

Jest to omówione w dokumentacji wtyczki Git w witrynie Jenkins w sekcji: Recursive submodules .

fragment

Wtyczka GIT obsługuje repozytoria z podmodułami, które z kolei same mają podmoduły. Należy to jednak włączyć: w Job Configuration -> Section Source Code Management , Git -> Advanced Button (w sekcji Branches to build) -> Recursively update submodules .

Przykład

Na ekranie konfiguracji zadania, w sekcji Zarządzanie kodami źródłowymi, pociągnij przycisk Dodaj w dół i wybierz opcję „Zaawansowane zachowanie podmodułów”.

Następnie wybierz „Rekurencyjnie aktualizuj moduły podrzędne”:

— slm
źródło

1

dziękuję, ale to nie działało w czasie, gdy próbowałem tego (prawie 2 lata temu)

— Ben

@Ben - OK, właśnie spróbowałem i zadziałało. Może być powiązany z twoimi wersjami.

— slm

1

Działa to tylko wtedy, gdy repozytorium nie wymaga uwierzytelniania do odczytu modułu podrzędnego git.

— Ernst Kuschke

@ErnstKuschke - Uważam, że Jenkins może otrzymać klucz SSH, aby mógł również współpracować z repozytoriami, które wymagają uwierzytelniania.

— slm

29

Czy wiesz, że repozytorium Git zawsze odnosi się do określonej wersji modułu podrzędnego? Jenkins nie zamierza automatycznie zmieniać wersji.

Jeśli chcesz korzystać z nowszej wersji modułu podrzędnego, musisz to zrobić w swoim lokalnym repozytorium Git:

cd submoduledir
git pull
cd ..
git add submoduledir
git commit -m 'Updated to latest revision of submoduledir'
git push # Go and watch Jenkins build with the new revision of the submodule

Kiedy zrobisz to w ten sposób, Jenkins sprawdzi dokładnie tę samą wersję podmodułu podczas kompilacji. Jenkins nie decyduje samodzielnie, której wersji podmodułu użyć. Jest to podstawowa różnica między podmodułami Git a zewnętrznymi programami SVN.

Możesz przeczytać dobre referencje na temat modułów podrzędnych, np . Http://progit.org/book/ch6-6.html .

— sti
źródło

1

Link ProGit podany przez @sti jest nieaktualny. Myślę, że to aktualny odpowiednik https://git-scm.com/book/en/v2/Git-Tools-Submodules

— Stevel

Łącze jest zepsute (związane z HTTPS?) - „502 Bad Gateway” .

— Peter Mortensen

17

W końcu natknąłem się na sposób, aby to zrobić i jest to proste.

Problem:

Początkowy klon z poświadczeniami działa prawidłowo, ale kolejne submoduleklonowanie kończy się niepowodzeniem z nieprawidłowymi poświadczeniami.

Automatyczne zaawansowane klonowanie modułu podrzędnego Source Code Management >> Additional Behaviours >> Advanced sub-modules behaviours:: powoduje błąd poświadczeń.
git submodule update --initw Execute Shellsekcji również kończy się niepowodzeniem z błędem poświadczeń.

Rozwiązanie:

Używam jenkins-1.574.

Zaznacz Build Environment >> SSH Agentpole.
Wybierz prawidłowe poświadczenia (prawdopodobnie takie same, jak wybrane w Source Code Managementsekcji

Zaktualizuj moduły podrzędne w Execute Shellsekcji

git submodule sync
git submodule update --init --recursive

Oto zrzut ekranu wprowadź opis obrazu tutaj

— potench
źródło

3

Nie ma już takiego pola wyboru.

— adi518

11

Wygląda na to, że znalazłem rozwiązanie:

Dodałem krok kompilacji, aby wykonać następujące polecenia powłoki:

git submodule foreach git checkout master
git submodule foreach git pull

— Ben
źródło

Po wykonaniu tych poleceń może być jednak konieczne zatwierdzenie w superprojekcie, ponieważ HEAD w twoich podmodułach zostanie zaktualizowany.

— slacy

Cześć Ben, czy mógłbyś przedstawić swoje rozwiązanie bardziej szczegółowo? Chcę zrobić to samo. Ponadto, aby potwierdzić, Twoje rozwiązanie spowoduje aktualizację podmodułów projektu do obszaru roboczego, tak?

— Kim Stacks

nie ma o wiele więcej szczegółów niż to. Właśnie dodałem te 2 linie do mojego procesu kompilacji i zawsze pobiera najnowszą wersję modułu podrzędnego.

— Ben

10

Jak @sti mówi w innej odpowiedzi, wygląda na to, że próbujesz używać podmodułów Git, takich jak zewnętrzne SVN. Zamiast dodawać te polecenia do Jenkinsa, lepiej byłoby wysłać odpowiednie wersje podmodułów do głównego repozytorium Git. Jenkins będzie wtedy zawsze sprawdzać tę samą wersję modułów podrzędnych podczas budowania określonej wersji projektu. Powtarzalne kompilacje to dobra rzecz.

— Cody Casterline

4

@ben Natknąłem się na to polecenie, które może okazać się bardziej przydatne, mimochodem, jeśli nie używasz gałęzi master w module podrzędnym git submodule update --init --recursive

— Corey Scott,

7

Jeśli używasz modułu Jenkins Git, możesz ustawić go na „Wyczyść obszar roboczy przed budową”, w ten sposób zawsze otrzyma właściwy moduł podrzędny.

— Amin Y
źródło

2

Używam skryptowego potokowania z wtyczką do kasy. Jeśli chcesz, aby moduły podrzędne były takie same jak w repozytorium, po prostu wyłącz opcję trackingSubmodules w następujący sposób:

checkout([$class: 'GitSCM', branches: [[name: '*/develop']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'SubmoduleOption', disableSubmodules: false, parentCredentials: true, recursiveSubmodules: false, reference: '', trackingSubmodules: false]], submoduleCfg: [], userRemoteConfigs: [[credentialsId: '[myCredentials]', url: 'https://git.myRepo.git']]])

— Jochen Gunzelmann
źródło