Gemeinsame Nutzung von Build-Artefakten zwischen Jobs in Hudson

Question

Ich versuche, unseren Build-Prozess in Hudson einzurichten.

Job 1 wird ein superschneller (hoffentlich) Continuous-Integration-Build-Job sein, der häufig erstellt wird.

Job 2 ist für die Durchführung einer umfassenden Testsuite in regelmäßigen Abständen oder manuell ausgelöst verantwortlich.

Aufgabe 3 ist für die Ausführung von Analysetools in der gesamten Codebasis zuständig (ähnlich wie Aufgabe 2).

Ich habe versucht, die Funktion "Erweiterte Projektoptionen > Benutzerdefinierten Arbeitsbereich verwenden" zu verwenden, damit der in Job 1 kompilierte Code in Job 2 und 3 verwendet werden kann. Es scheint jedoch, dass alle Build-Artefakte innerhalb des Arbeitsbereichs von Job 1 bleiben. Mache ich das richtig? Gibt es eine bessere Möglichkeit, dies zu tun? Ich schätze, ich bin auf der Suche nach etwas ähnlichem wie eine Build-Pipeline-Setup ..., so dass Dinge geteilt werden können und die entsprechenden Aufträge in Phasen ausgeführt werden können.

(Ich habe auch die Verwendung von "Batch-Aufgaben" in Erwägung gezogen... aber es scheint, dass diese nicht geplant werden können, sondern nur manuell ausgelöst werden können...)

Alle Vorschläge sind willkommen. Danke!

Answer 1

Versuchen Sie es doch einmal mit dem Plugin Copy Artifact:

http://wiki.hudson-ci.org/display/HUDSON/Copy+Artefakt+Plugin

Ihr kontinuierlicher Job kann die notwendigen Artefakte erstellen, und Ihre beiden anderen Jobs können sie zur Analyse heranziehen.

Answer 2

Hudson hat ein Plugin für genau dieses Problem: http://wiki.hudson-ci.org/display/HUDSON/Clone+Arbeitsbereich+SCM+Plugin (Link derzeit defekt)

Die entsprechende Jenkins-Seite finden Sie hier: https://wiki.jenkins-ci.org/display/JENKINS/Clone+Arbeitsbereich+SCM+Plugin

Answer 3

Ja, die Wiki-Seite war nicht sehr hilfreich, da sie versucht, das Ganze sehr elegant erscheinen zu lassen. Die Wahrheit ist, dass Hudson Job-Ketten noch nicht sehr elegant unterstützt, wenn man Dinge von einem Job an einen anderen übergeben muss.

Ich verwende auch die Methode "zip-up-and-copy-workspace", um Arbeitsbereiche von einem Auftrag auf einen anderen zu übertragen. Ich habe einen Quick-Build, einen vollständigen Analyse-Build und dann Distributions-Builds. Dazwischen verwende ich Ant, um Zeitstempel und "Build-Stamps" zu erzeugen, um zu markieren, welche Jobnummer die Nummer eines anderen Jobs erstellt hat. Die Fingerprinting-Funktion hilft dabei, die Dateien zu verfolgen, aber da ich die Workspace-Zips nicht archiviere, ist das Fingerprinting für die Benutzer nutzlos, da sie die Workspace-Zips nicht sehen können.

Answer 4

Haben Sie sich das Hudson-Wiki angesehen? Genauer gesagt: Aufteilung eines großen Auftrags in kleinere Aufträge

Answer 5

Ich hatte das gleiche Problem, und ich habe mich für separate Projekte für die lang laufenden Aufgaben entschieden. Der erste Schritt in diesen Projekten bestand darin, alle Dateien aus dem Arbeitsbereich von Job 1 (d. h. dem letzten Build) in die Arbeitsbereiche von Job 2/3/etc zu kopieren. Dies funktionierte in der Regel, es sei denn, Job 1 baute zum Zeitpunkt des Starts von Job 2/3 gerade, da er dann einen unvollständigen Arbeitsbereich erhielt. Man könnte dies umgehen, indem man das "Ende des Builds" in Job 1 mit einer Sentinel-Datei erkennt oder das Hudson Locks Plugin verwendet (ich habe es nicht ausprobiert).

Sie haben keine haben einen benutzerdefinierten Arbeitsbereich zu verwenden, wenn Sie Annahmen über die Platzierung der anderen Jobs relativ zu %WORKSPACE% treffen.