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

So etwas mache ich jetzt auch. Ich würde empfehlen, nicht zu versuchen, viele Aufträge in demselben gemeinsamen Arbeitsbereich laufen zu lassen. Ich habe damit nur Probleme gehabt.

Ich verwende Maven und den Typ Freiform-Projekte. Ein Satz von Aufträgen wird ausgeführt, wenn die Dateien im Versionskontrollsystem dies auslösen. Sie erstellen lokale Snapshot-Artefakte. Eine zweite Gruppe von Aufträgen wird nachts ausgeführt und richtet eine Integrationstestumgebung ein, in der dann Tests durchgeführt werden.

Wenn Sie Maven nicht verwenden, besteht eine Möglichkeit darin, einen Bereich auf der Festplatte einzurichten und die letzten Schritte von Job eins die Artefakte dorthin zu kopieren. Die ersten Schritte von Job zwei sollten darin bestehen, diese Dateien dorthin zu verschieben. Führen Sie aus, was immer Sie ausführen müssen.

Was die dritte Aufgabe angeht, so gibt es jetzt findbugs/checkstyle/pmd und alle anderen Plugins für Hudson. Ich würde empfehlen, einfach eine Version von Job 1 zu erstellen, die einen sauberen nächtlichen Checkout durchführt und diese auf Ihrer Codebasis ausführt.

Answer 2

Hudson scheint kein eingebautes Repository für Build-Artefakte zu haben. Unsere Lösung war, eines zu erstellen.

Da wir in einer Windosw-Umgebung arbeiten, habe ich eine Freigabe erstellt, auf die alle Hudson-Server zugreifen können (wir geben den betreffenden Diensten ein gemeinsames Konto, da das Systemkonto nicht auf Ressourcen im Netzwerk zugreifen kann).

In unseren Build-Skripten (ant) gibt es Aufgaben, die von anderen Jobs erstellte Ressourcen in den lokalen Arbeitsbereich kopieren, und Jobs, die Artefakte erzeugen, kopieren diese in das gemeinsame Repository.

In anderen Umgebungen können Sie Dateien über FTP oder einen anderen Mechanismus zur Übertragung von Dateien veröffentlichen und abrufen.

Vereinfachte Beispiele für Veröffentlichungs- und Abrufaufgaben:

<!-- ==================== Publish ==================================== -->
<target name="Publish" description="Publish files">
  <mkdir dir="${publish.dir}/lib" />
  <copy todir="${publish.dir}/lib" file="${project.jar}"/>
</target>

und

<!-- ==================== Get ==================================== -->
<target name="getdependencies" description="Get necessary results from published directory">
  <copy todir="${support.dir}">
    <fileset dir="${publish.dir}/lib">
      <include name="*.jar"/>
    </fileset>
  </copy>
</target>

Answer 3

Ich stimme zu, dass das derzeitige manuelle Kopieren von Dateien/Artefakten/Arbeitsbereichen zwischen Aufträgen nicht gerade elegant ist.

Außerdem fand ich es platz- und zeitraubend, riesige tgz/zip-Dateien zu archivieren. In unserem Fall waren diese Dateien riesig (1,5 GB) und das Packen/Archivieren/Fingerprinting/Entpacken nahm viel Zeit in Anspruch.

Also habe ich mich mit einer leicht optimierten Variante desselben begnügt:

• Job 1/2/3 checken/klonen alle das gleiche Quell-Repository, aber
• Job 1 packt nur Dateien, die tatsächlich Build-Artefakte sind
  • mit Git macht dies einfach und schnell durch git ls-files -oz nicht sicher über andere SCMs
• Verwendung des Plugins Copy Artifact zur Übertragung von Dateien
• Dies reduziert diese Dateien auf 1/3 der Größe in unserem Fall -> Beschleunigung, weniger Platzverschwendung