2010-02-15 8 views
5

Es gibt 4 Jobs:Wie Jobs in Hudson in einer vordefinierten Reihenfolge ausgeführt werden?

Build1 
Build2 
Test1 
Test2 

build1 und build2 gleichzeitig gestartet werden kann.
Test1 sollte nur begonnen werden, wenn beide build1 und build2 abgeschlossen sein wird.
Tes2 sollte nur gestartet werden, wenn Tes1 wird beendet.
Auch möchte ich die Fähigkeit haben, alle diese Jobs separat zu starten.
Gibt es eine Möglichkeit, Jobs nach diesen Regeln einzurichten?

Antwort

4

Beim Erstellen eines neuen Jobs können Sie normalerweise angeben, welches Upstream-Projekt erstellt werden muss, um diesen Job zu starten.

Diese Option ist in Erstellen von Triggern -> Erstellen, nachdem andere Projekte erstellt wurden beim Erstellen/Ändern eines Jobs.

+0

Ich möchte ** Build1 ** und ** Build2 ** gleichzeitig starten. Aber ich kann ** Test1 ** nicht konfigurieren, um es zu starten, wenn sowohl ** Build1 ** als auch ** Build2 ** fertig sind. Es ist möglich, ** Test1 ** zu starten, wenn entweder ** Build1 ** oder ** Build2 ** beendet ist. Habe ich recht? –

+0

Sie müssen auch unter Erweiterte Projektoptionen die Option "Build blockieren, wenn das Upstream-Projekt erstellt wird" aktivieren. Dies verhindert, dass Test1 erstellt wird, wenn sich Build1 oder Build2 in der Warteschlange befinden. –

+0

Ich habe keine solche Option. Welche Version von Hudson benutzt du? –

2

Ich denke, Sie haben mehrere Möglichkeiten. Meine Annahme ist, dass wir über lange laufende Jobs sprechen, ansonsten würde ich sie einfach als einen Monsterjob zusammenführen (mehrere Buildschritte in einem Job) und separate Jobs erstellen, um sie einzeln auszuführen.

Wie bereits erwähnt, schauen Sie sich für lang laufende Jobs die join plugin an. Als allgemeine FYI gibt es eine Seite, die erklärt, warum Sie Testjobs von den Baujobs trennen möchten. Siehe here.

+0

Das Join-Plugin ist hier der Schlüssel. –

0

Ich habe Version 1.346 von Hudson.

Sie können "Build, nachdem andere Projekte gebaut werden" unter "Build Trigger" überprüfen.

Er sagt, dass „Mehrere Projekte können wie angegeben werden‚abc, def‘“

Sie also sollte der Lage sein, hinzufügen ‚build1, build2‘ auf diesem Gebiet in der Konfiguration für Test1.

+0

Aus dem Hilfetext für 'Build after projects are build': * Richten Sie einen Trigger ein, so dass nach Abschluss der Erstellung einiger anderer Projekte ein neuer Build für dieses Projekt geplant ist. Dies ist praktisch, wenn nach Abschluss eines Builds beispielsweise ein umfangreicher Test ausgeführt werden soll. * - also wird Test1 im Wesentlichen ausgelöst, wenn entweder ein oder zwei Builds ausgeführt werden, nicht nach zwei. In diesem speziellen Fall können Sie dieses Problem mit dem Locks-and-Latches-Plugin umgehen. –

0

Sie könnten Ihren Test1 & Test2 als separate Jobs behalten, anstatt ein Teil der Builds zu sein.

Wenn Build1 und Build2 abgeschlossen sind, kann Test1 als Downstream-Build gestartet werden. Test2 kann ein nachgelagerter Job von Test1 sein.

1

Das "Promoted Builds Plugin" kann eine gute Lösung sein: Sie können einen Master-Job "Build" konfigurieren, um nur zwei nachgeordnete Builds "Build1, Build2" (in Post-Build-Aktionen) zu starten. Dann müssen Sie einen Promotion-Prozess "Wenn die folgenden Downstream-Projekte erfolgreich erstellen" hinzufügen "Build1, Build2", mit einer zugehörigen Downstream-Build-Aktion von "Test1" hinzufügen. Wenn "Build1" und "Build2" erfolgreich erstellt werden (beide Status STABLE), wird "Build" hochgestuft und "Test1" wird in die Warteschlange eingereiht. Schließlich lösen Sie Test2 als eine Post-Build-Aktion von Test1 aus.

Aber Sie müssen beachten, dass Fall viele Instanzen von "Build" eingereiht sind, können Sie nicht auf die LASTSuccessful Build-Permalink verlassen (die nächste "Build1" oder "Build2" kann bereits erstellt werden, wenn "Test1" von aufgerufen Der erste "Build" wird aus der Warteschlange herauskommen, und Sie müssen einen Weg finden, um die Revision des zu testenden Builds zu verfolgen.

Das parametrierte Trigger-Plugin kann helfen, dieses Problem zu lösen: Sie könnten beispielsweise die ID des Upstream-Builds als Parameter übergeben.

Verwandte Themen