Obejście: wyniki testów końcowych agregacji

Question

O ile mi wiadomo, funkcja "Łączne wyniki testów końcowych" nie działa zgodnie z oczekiwaniami (i bardzo trudno jest znaleźć przydatną dokumentację). Chciałbym osiągnąć bardzo podobną funkcjonalność:

Job Zbuduj wyzwala pracy T1, T2 równolegle (gdzie T1 robi FindBugs, T2 robi PMD).

Scenariusz 1: Jak tylko T1 i T2 są wykończone (co można osiągnąć za pomocą wtyczki "join") Chcę zebrać artefakty (T1 /findbugs.xml i T2 /pmd.xml). Następnie są analizowane i generowane są ładne statystyki.

Scenariusz 2 (i jak to dalej) jak scenariuszu 1, ale analiza jest wykonywana jako element T1 i T2(równolegle!). Po ukończeniu T1 i T2 wyniki analizy są łączone w ładne statystyki.

Moje pytania: Dla scenariusza 1 nie wiem jak odwołać się do downstream projektom T1 i T2. Mogłem użyć ostatniej udanej wersji, ale wydaje się to dziwne, gdy rozważa się wiele równoległych zadań.

W scenariuszu 2 nie mam pojęcia, jak importować dane, które są potrzebne do FindBugs/PMD/Checkstyle/sloccount/... wtyczki tak, że odpowiednie wykresy (także?) Pojawiają się poza T1/* T2 *.

Dzięki Carsten

Answer 1

Dwa dodatki do postu malenkiy_scot za:

1. rzeczywistości nie potrzebują scenariusz do kroku 3 w opis: „artefakty kopia z innego projektu” budować krok umożliwia określenie zadania źródłowego tym już parametrów .

   Na przykład, korzystając z notacji rodzica, może on kopiować artefakty z prawidłowego wykonania zadania D, używając D/PARENT_ID=EXPECTED_VALUE jako "nazwy projektu".

2. Zamiast ręcznie łącząc $JOB_NAME i $BUILD_ID można użyć predefiniowanych $BUILD_TAG (który ma zasadniczo takie same). Zobacz https://wiki.jenkins-ci.org/display/JENKINS/Building+a+software+project#Buildingasoftwareproject-JenkinsSetEnvironmentVariables, aby uzyskać pełną listę standardowych zmiennych środowiskowych.

Answer 2

Oto zarys na nieco prostszym scenariuszu, ale myślę, że można łatwo uogólnić go do przypadku wielu prac końcowych. Sztuką jest używanie parametrów "znakowania" w dalszych zleceniach.

Pozwól, że P będzie pracą nadrzędną, a praca podrzędna będzie stanowić D.

1. Wystąpienie (budowa) w P wywołuje D poprzez Parameterized Trigger Plugin poprzez etap gromadzenia (nie jako krok po kompilacji) i czeka na D jest do końca. Wraz z innymi parametrami, P przechodzi do D parametrem - nazwijmy to PARENT_ID - na podstawie P „s build na BUILD_ID.
2. D wykonuje testy i archiwizuje je jako artefakty (wraz z raportami jUnit - jeśli dotyczy).
3. P następnie realizuje Python zewnętrznego (lub wewnętrznego Groovy) skrypt, który znajdzie odpowiednią kompilację D poprzez PARENT_ID (iteracyjne nad buduje D i zbadać wartość PARENT_ID parametru). Skrypt następnie kopiuje artefakty z D do P.

Jeśli używasz Pythona (to właśnie robię) - używaj Python JenkinsAPI wrapper. Jeśli korzystasz z Groovy - użyj Groovy Plugin i uruchom skrypt jako skrypt systemowy. Następnie możesz uzyskać dostęp do Jenkinsa poprzez jego Java API.

Answer 3

Jenkins Plugin https://wiki.jenkins-ci.org/display/JENKINS/Build+Flow+Plugin powinien pomóc w takich wymaganiach.