Wyewidencjonuj wiele repozytoriów git do tego samego obszaru roboczego Jenkins


127

Korzystanie z Jenkins 1.501 i wtyczki Jenkins Git 1.1.26

Mam 3 różne repozytoria git, każdy z wieloma projektami.

Teraz muszę wyewidencjonować wszystkie projekty z 3 repozytoriów git do tego samego obszaru roboczego na serwerze podrzędnym Jenkins. Każde repozytorium git zdefiniowałem w: Zarządzanie kodem źródłowym: Wiele SCM . Ale za każdym razem, gdy repozytorium jest sprawdzane, poprzednie repozytorium (i powiązane z nim projekty) jest usuwane.

Przeczytałem to:

http://jenkins.361315.n4.nabble.com/multiple-git-repos-in-one-job-td4633300.html

ale to naprawdę nie pomaga. Próbowałem określić ten sam folder w podkatalogu lokalnym dla repozytorium (opcjonalnie) dla wszystkich repozytoriów, ale daje ten sam wynik.

Jeśli jest to po prostu niemożliwe przy użyciu Jenkinsa, przypuszczam, że można użyć jakiegoś kroku / skryptów przed kompilacją, aby przenieść projekty we właściwe miejsce. Nie można modyfikować konfiguracji kompilacji projektów.

Odpowiedzi:


69

Wyewidencjonowanie więcej niż jednego repozytorium na raz w jednym obszarze roboczym nie jest możliwe dzięki wtyczce Jenkins + Git.

Aby obejść ten problem, możesz albo mieć wiele zadań nadrzędnych, z których każde pobiera po jednym repozytorium, a następnie kopiuje do ostatecznego obszaru roboczego projektu (problematyczne na wielu poziomach), lub możesz skonfigurować krok skryptów powłoki, który sprawdza każde potrzebne repozytorium, aby obszar roboczy zadania w czasie kompilacji.

Wcześniej wtyczka Multiple SCM mogła pomóc w rozwiązaniu tego problemu, ale teraz jest przestarzała. Ze strony wtyczki Multiple SCM: „Użytkownicy powinni przejść na https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin . Pipeline oferuje lepszy sposób sprawdzania wielu SCM i jest obsługiwany przez Jenkins podstawowy zespół programistów. ”


Dlaczego pierwsze podejście jest problematyczne? Dzielenie pracy wydaje się dobrą praktyką.
CurtainDog,

1
Ogólnie jest to dobra praktyka, ale gdy potrzebujesz wielu kas w tej samej lokalizacji fizycznej, utrzymanie staje się poważnym problemem. Na przykład, jeśli chcesz utworzyć kompilację gałęzi, musisz sklonować 4 zadania, a następnie indywidualnie zmienić ścieżki dla każdego z nich. Istnieją oczywiście wtyczki, które w tym pomagają, ale łatwiej jest po prostu przejść do względnej ścieżki z jednego zadania. Następnie możesz klonować tyle, ile chcesz, bez zmiany ustawień.
CIGuy

1
Musisz zmienić ją z prawidłowej odpowiedzi, ponieważ nie ma już znaczenia.
Dvir669

2
Potoki wymagają nauczenia się nowego DSL, co jest trochę za dużo jak na bardzo proste zadanie (sprawdzenie kodu z wielu repozytoriów), które chcemy wykonać. Trzymaj się wtyczki Multiple SCM, aż przyzwoity GUI pojawi się wokół DSL potoku Jenkins. Mogę zgłosić, że działa dobrze z Jenkinsem 2.17
Burak Arslan

2
Właśnie napotkałem te same problemy z wieloma repozytoriami. Używam teraz wtyczki Pipeline, mimo że byłem tak samo sceptyczny jak @BurakArslan w sprawie nowego DSL. Właściwie nie jest tak źle, jak myślałem i zawiera całkiem przyzwoity generator fragmentów. Używając go tylko przez 2 godziny, wolę teraz to podejście, ponieważ ostatecznie mogę zatwierdzić skrypty budujące potok do gita razem z resztą kodu.
Ben

81

Dzięki wtyczce Multiple SCMs:

  • utwórz inny wpis repozytorium dla każdego repozytorium, które chcesz pobrać (projekt główny lub projekt zależny.

  • dla każdego projektu, w menu „zaawansowane” (drugie menu „zaawansowane”, dla każdego repozytorium są dwa przyciski oznaczone jako „zaawansowane”), znajdź pole tekstowe „Lokalny podkatalog dla repozytorium (opcjonalne)”. Możesz w nim określić podkatalog w katalogu „workspace”, do którego chcesz skopiować projekt. Możesz zmapować system plików mojego komputera deweloperskiego.

„Drugie menu zaawansowane” już nie istnieje, zamiast tego należy użyć przycisku „Dodaj” (w sekcji „Dodatkowe zachowania”) i wybrać opcję „Sprawdź do podkatalogu”

  • jeśli używasz ant, ponieważ teraz plik build.xml z celami kompilacji nie znajduje się w katalogu głównym obszaru roboczego, ale w podkatalogu, musisz to uwzględnić w konfiguracji „Invoke Ant”. Aby to zrobić, w polu „Wywołaj mrówkę” naciśnij „Zaawansowane” i wypełnij tekst wejściowy „Buduj plik”, łącznie z nazwą podkatalogu, w którym znajduje się plik build.xml.

Mam nadzieję, że to pomoże.


3
To musi być nieaktualne. W chwili pisania tego tekstu fragment kodu GIT wtyczki Multiple SCM nie zawiera opcjonalnej ścieżki podrzędnej.
AlexeiOst

12
W każdym repozytorium znajduje się rozwijana lista o nazwie „Dodaj”. Można w nim znaleźć opcję „Sprawdź do podkatalogu”, która spełnia to samo zadanie.
Gary Ye

1
Podążałem za twoim przewodnikiem z wieloma wtyczkami SCM i gitem, ale mam inny zabawny problem. Wydaje się, że nie chce poprawnie pobierać tej samej gałęzi (rozwijać) dla różnych repozytoriów. Próbuje pobrać zatwierdzenie przez hash (który jest ważny tylko w pierwszym repozytorium). Masz jakiś pomysł, jak rozwiązać ten problem?
Lefteris

Największym problemem związanym z wieloma wtyczkami SCM jest to: „Wyzwalacze typu post-commit obecnie nie działają (przynajmniej dla subversion), więc konieczne jest skonfigurowanie odpytywania typu 'cron'.”
grayaii

1
Potoki wymagają nauczenia się nowego DSL, co jest trochę za dużo jak na bardzo proste zadanie (sprawdzenie kodu z wielu repozytoriów), które chcemy wykonać. Trzymaj się wtyczki Multiple SCM, aż przyzwoity GUI pojawi się wokół DSL potoku Jenkins. Mogę zgłosić, że działa dobrze z Jenkins 2.17
Burak Arslan

41

Ponieważ wtyczka Multiple SCMs jest przestarzała.

Dzięki Jenkins Pipeline można sprawdzić wiele repozytoriów git i po zbudowaniu go przy użyciu gradle

node {   
def gradleHome

stage('Prepare/Checkout') { // for display purposes
    git branch: 'develop', url: 'https://github.com/WtfJoke/Any.git'

    dir('a-child-repo') {
       git branch: 'develop', url: 'https://github.com/WtfJoke/AnyChild.git'
    }

    env.JAVA_HOME="${tool 'JDK8'}"
    env.PATH="${env.JAVA_HOME}/bin:${env.PATH}" // set java home in jdk environment
    gradleHome = tool '3.4.1' 
}

stage('Build') {
  // Run the gradle build
  if (isUnix()) {
     sh "'${gradleHome}/bin/gradle' clean build"
  } else {
     bat(/"${gradleHome}\bin\gradle" clean build/)
  }
}
}

Możesz rozważyć użycie podmodułów git zamiast niestandardowego potoku, takiego jak ten.


Dziękuję Ci!!! dirBlok jest kluczem, nie mogłem zrozumieć, dlaczego ja tylko widząc najbardziej niedawno sklonowane repo w obszarze roboczym moja praca jest.
bonh

jak rozpatruje się pojęcie „zmian” w przypadku wielu SCM? Czy to tylko suma zmian widocznych ze wszystkich repozytoriów, które składają się na zadania? Dobrze byłoby wyszczególnić je z każdego, jeśli to możliwe, 23 changes from repo XXX, 3 changes from repo YYYlub coś bardziej zwięzłego w tym zakresie.
jxramos

20

3
dzięki, to świetnie, jestem w stanie umieścić 2 ścieżki bitbucket w sekcji repozytorium, a teraz jak mogę powiedzieć, że gałąź "develop" repo 1 checkout i dla gałęzi "fixes" repo 2 checkout? widzę gałęzie do zbudowania w jenkins, w jaki sposób mogę ustawić nazwę repozytorium i Refsec w specyfikatorze gałęzi (puste dla „dowolnego”), aby każdy z nich mógł sprawdzić odpowiednią gałąź, którą chcę? czy robię to wront i powinienem kliknąć logiczną z napisem „Wiele SCM”?
pelos

@pelos Czy udało Ci się znaleźć rozwiązanie?
Govind

w tej chwili nie używamy pliku yml i wykonaliśmy dwa różne przepływy pracy ze zwykłymi zadaniami
pelos

5

W zależności od relacji między repozytoriami, innym podejściem jest dodanie drugiego repozytorium (repozytoriów) jako podmodułów git do jednego z repozytoriów. Podmoduł git tworzy odniesienie do innych repozytoriów. Te repozytoria podmodułów nie są klonowane, chyba że użytkownik określi --recursiveflagę podczas klonowania „superprojektu” (termin oficjalny).

Oto polecenie dodania modułu podrzędnego do bieżącego projektu:

git submodule add <repository URI path to clone>

Używamy Jenkins w wersji 1.645, a git SCM zaraz po wyjęciu z pudełka wykona rekurencyjny klon dla superprojektów. Voila, otrzymujesz pliki superprojektu i wszystkie zależne (podmoduły) pliki repozytorium w ich własnych odpowiednich katalogach w tym samym obszarze roboczym Jenkins.

Nie poręczam, że jest to właściwe podejście, a raczej podejście.


5

Jenkins: wiele SCM - przestarzałe. Wtyczka GIT - nie działa dla wielu repozytoriów.

Skrypty / potok jako kod - to droga.


2

Ja też miałem ten problem. Rozwiązałem to używając Trigger / call builds w innych projektach. Dla każdego repozytorium nazywam projekt podrzędny za pomocą parametrów.

Główny projekt:

This project is parameterized
String Parameters: PREFIX, MARKETNAME, BRANCH, TAG
Use Custom workspace: ${PREFIX}/${MARKETNAME}
Source code management: None

Następnie dla każdego repozytorium nazywam projekt podrzędny w następujący sposób:

Trigger/call builds on other projects: 
Projects to build: Linux-Tag-Checkout
Current Build Parameters
Predefined Parameters: REPOSITORY=<name>

Projekt podrzędny: Linux-Tag-Checkout:

This project is parameterized
String Parameters: PREFIX, MARKETNAME, REPOSITORY, BRANCH, TAG
Use Custom workspace:${PREFIX}/${MARKETNAME}/${REPOSITORY}-${BRANCH}
Source code management: Git
git@<host>:${REPOSITORY}
refspec: +refs/tags/${TAG}:refs/remotes/origin/tags/${TAG}
Branch Specifier: */tags/${TAG} 

1

Wyrejestrowanie więcej niż jednego repozytorium na raz w jednym obszarze roboczym jest możliwe dzięki wtyczce Jenkins + Git (może tylko w nowszych wersjach?).

W sekcji „Source-Code-Management” nie wybieraj „Git”, ale „Multiple SCM” i dodaj kilka repozytoriów git.

Upewnij się, że we wszystkich oprócz jednego dodasz jako „Dodatkowe zachowanie” akcję „Sprawdź do podkatalogu” i określ indywidualny podkatalog.


Uważam, że w ten sposób używasz (przestarzałej) wtyczki Multiple SCM zamiast zwykłej wtyczki Git.
Robert

0

Używamy git-repo do zarządzania naszymi wieloma repozytoriami GIT. Istnieje również wtyczka Jenkins Repo, która umożliwia wyewidencjonowanie całości lub części repozytoriów zarządzanych przez git-repo do tego samego obszaru roboczego Jenkins.


Jak dokładnie rozwiązujesz problem zadany w tym pytaniu? Zainstalowałem wspomnianą wtyczkę i poczytałem o repozytorium i wtyczce, ale nie widzę, jak skonfigurować Jenkinsa do sklonowania dwóch repozytoriów w celu wykonania w jednym projekcie ...
GreenAsJade

Aby korzystać z Repo, należy utworzyć specjalne repozytorium, które będzie zawierało tylko plik (i) manifestu. W tym pliku określasz wszystkie informacje o innych repozytoriach. Dokładny format plików manifestu jest opisany w pliku docs / manifest-format.txt projektu git-repo ( gerrit.googlesource.com/git-repo/+/master/docs/… ). Podczas konfigurowania części zadania Jenkins Repo - określasz lokalizację repozytorium „manifestu” i opcjonalnie nazwę plików „manifestu” (możesz mieć kilka). Wszystkie repozytoria określone w manifeście zostaną sklonowane.
vladisld
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.