it-swarm.com.de

Jenkins und Multi-Configuration-Jobs (Matrix)

Warum gibt es zwei Arten von Jobs für Jenkins, sowohl das Multi-Configuration-Projekt als auch das Free-Style-Projekt? Ich habe irgendwo gelesen, dass, wenn Sie sich für eines von ihnen entschieden haben, Sie nicht einfach in das andere konvertieren können. Warum sollte ich nicht immer das Multi-Konfigurationsprojekt auswählen, um für zukünftige Änderungen sicher zu sein?

Ich möchte ein Build für ein Projekt einrichten, das sowohl unter Windows als auch unter Unix (und auch auf anderen Plattformen) erstellt wird. Ich habe diese Frage ) gefunden, die dasselbe verlangt, aber ich bekomme die Antwort nicht wirklich. Warum brauche ich drei Matrixprojekte (und nicht drei frei gestaltete Projekte), eines für jede Plattform? Warum kann ich sie nicht alle in einer Matrix halten, mit Plattformen UND (z. B.) gcc-Version auf einer Achse und (meinen) Softwareversionen auf der anderen Achse?

Ich lese auch diesen Blogbeitrag , aber das baut alles auf derselben Maschine auf, nur mit verschiedenen Python-Versionen.

Kurz gesagt: Wie konfigurieren die meisten Benutzer ein Projekt mit mehreren Konfigurationen, das auf viele verschiedene Plattformen abzielt?

38
joscarsson

Die zwei Arten von Jobs haben separate Funktionen:

  • Free-Style-Jobs: Damit können Sie Ihr Projekt auf einem einzelnen Computer oder Etikett erstellen (eine Gruppe von Computern, zum Beispiel "Windows-XP-32"). 
  • Jobs mit mehreren Konfigurationen: Mit diesen können Sie Ihr Projekt auf mehreren Computern oder Labels oder einer Kombination der beiden erstellen, z. B. Windows-XP, Windows-Vista, Windows-7 und RedHat -, die sich zum Überprüfen der Kompatibilität oder zum Erstellen von Dateien eignen mehrere Plattformen (qt-Programme?)

Wenn Sie ein Projekt haben, das Sie unter Windows und Unix erstellen möchten, haben Sie zwei Möglichkeiten:

  • Erstellen Sie für jede Konfiguration einen separaten Job im freien Stil. In diesem Fall müssen Sie jeden Job einzeln pflegen
  • Sie haben one multi-configuration job und wählen 2 (oder mehr) Labels/Computer/Slaves aus - 1 für Windows und 1 für Unix. In diesem Fall müssen Sie nur einen Job für den Build verwalten

Sie können Ihre gcc-Versionen auf einer Achse und Softwareversionen auf einer anderen Achse beibehalten. Es gibt keinen Grund, warum Sie nicht dazu in der Lage sein sollten. 

Die Frage, die Sie verlinken, hat einen fairen Punkt, der sich jedoch nicht direkt auf Ihre Frage bezieht: In seinem Fall hatte er einen Job mit mehreren KonfigurationenA, der - bei Erfolg - einen anderen Job auslösteB. Wenn bei einem Auftrag mit mehreren Konfigurationen einer der Konfigurationen fehlschlägt, schlägt der gesamte Auftrag fehl (offensichtlich, da Ihr Projekt erfolgreich auf allen Ihren Konfigurationen erstellt werden soll). 

IMHO, für dasselbe Projekt auf mehreren Plattformen zu erstellen, ist der beste Weg, einen Job mit mehreren Konfigurationen zu verwenden. 

42
Sagar

Eine andere Option ist die Verwendung eines Python-Build-Schritts, um das aktuelle Betriebssystem zu überprüfen und anschließend ein entsprechendes Setup- oder Build-Skript aufzurufen. Im Python-Skript können Sie die aktualisierte Umgebung in einer Datei speichern und die Umgebung erneut mit dem EnvInject-Plugin für nachfolgende Erstellungsschritte einfügen. Abhängig von der Größe Ihrer Build-Umgebung können Sie auch ein Multi-Plattform-Build-Tool wie SCons verwenden.

6
Michael

Eine Option ist die Verwendung einer benutzerdefinierten Achse in Kombination mit Slaves (Windows, Linux, ...). Sie müssen also einen Filter für jede Kombination hinzufügen und das Conditional BuildStep Plugin verwenden, um den Erstellungsschritt für jede Plattform (Executar Shell) festzulegen , Windows-Befehl, ...) 

Dieser Link hat ein Tutorial, aber es ist auf Portugiesisch, aber es ist leicht, es anhand des Bildes ... http://manhadalasanha.wordpress.com/2013/06/20/projeto-de-multiplas zu erarbeiten -configuracoes-matrix-no-jenkins/

4
pauloremoli

Sie könnten ein Skript (z. B. build ) und eine Stapeldatei (z. B. build.bat ) erstellen, die mit Ihrem Quellcode eingecheckt werden. In Jenkins können Sie in Ihrem Build-Schritt $ WORKSPACE/build - aufrufen. Windows wird build.bat ausführen, während Linux build ausführt.

3
decocijo

Sie können die Variable verwenden, die Jenkins erstellt, wenn Sie eine Konfigurationsmatrixachse definieren. Zum Beispiel: Sie erstellen eine Slave-Achse mit dem Namen OSTYPE und überprüfen die beiden Slaves (Windows und Linux). Dann erstellen Sie zwei separate Erstellungsschritte und suchen nach der Umgebungsvariablen OSTYPE.

Sie können stattdessen eine verbesserte Skriptsprache verwenden, z. B. Python, die plattformübergreifend ist und unabhängig vom Namen der Slaves und in nur einem Erstellungsschritt dieselbe Funktionalität erreichen kann. 

2
Lucas Ces

Wenn Sie die Matrixroute mit Windows und etwas anderem verwenden, benötigen Sie das XShell-Plugin. Sie erstellen einfach Ihre beiden Build-Skripts wie "build.bat" für cmd und "build" für bash und weisen XShell an, "build" auszuführen. Die richtige wird jeweils ausgeführt.

2
Todd Greer

Warum sollten Sie nicht immer den Jobtyp mit mehreren Konfigurationen auswählen? 

Einige Gründe fallen ein:

  1. Weil Jobs einfach zu erstellen und zu konfigurieren sein sollten. Wenn es schwierig ist, einen Job in Ihrer Umgebung zu konfigurieren, machen Sie wahrscheinlich etwas falsches außerhalb des Jenkins-Jobs. Wenn Sie glücklich sind, dass Sie diesen einen Job erstellt haben und der Job schließlich ausgeführt wird und Sie diese gesamte Arbeit nur ungern wieder ausführen möchten, sollten Sie versuchen, sich zu verbessern.
  2. Weil Multi-Configuration-Jobs komplexer sind. Sie erfordern normalerweise, dass Sie sowohl über den Hauptjob als auch über die verschiedenen Subjobvariablen nachdenken und ihre Komplexität tendenziell auf ein Niveau anwächst, das über das überschaubare Niveau hinausgeht. In einem Szenario mit einem einzigen Job würden Sie wahrscheinlich Gedanken darüber verschwenden, dass Sie diese Komplexität nicht verwenden. Wenn Sie die Build-Variablen erweitern, können die Dinge in die falsche Richtung wachsen. Ich würde vorschlagen, die einfachen Jobs als Standard und die Multi-Konfigurations-Jobs nur dann zu verwenden, wenn mehrere Konfigurationen erforderlich sind.
  3. Da für die Ausführung von Multi-Configuration-Jobs möglicherweise mehr Jobplätze auf den Slaves benötigt werden als für einzelne Jobs. Es wird immer einen Master-Job geben, der auf einem speziellen, unsichtbaren Slot ausgeführt wird (dies stellt kein Problem dar) und löst die Sub-Jobs aus. Wenn diese Sub-Jobs jedoch selbst Sub-Jobs auslösen, können Sie leicht in einem Deadlock enden mehr Unteraufträge als Slots, und einige Unteraufträge lösen erneut Unteraufträge aus, die dann nicht ausgeführt werden können, da keine weiteren Slots mehr vorhanden sind. Dieses Problem kann umgangen werden, indem einige Konfigurationseinstellungen für die Slaves verwendet werden. Dieses Problem ist jedoch vorhanden und tritt nur auf, wenn mehrere Mehrfachaufträge gleichzeitig ausgeführt werden.

Grundsätzlich gilt: Der Multi-Configuration-Job ist komplexer. Da Komplexität vermieden werden sollte, wenn dies nicht notwendig ist, ist der reguläre Freestyle-Job eine bessere Standardeinstellung.

1
Sven

Ein Hack, damit Batch-Dateien unter Windows und Shell-Skripts unter Unix ausgeführt werden können:

Unter Unix lassen sich die Batchdateien mit dem Status 0 beenden beenden:

ln -s /bin/true /bin/cmd

Suchen Sie unter Windows entweder einen true.exe, benennen Sie ihn sh.exe und platzieren Sie ihn irgendwo im PATH.

Wenn Sie sh.exe unter Windows (Von Cygwin, Git oder einer anderen Quelle) installiert haben, fügen Sie dies alternativ zum Anfang des Shell-Skripts in Jenkins hinzu:

[ -n "$WINDIR" ] && exit 0

1
larsch

Wenn Sie auswählen möchten, auf welchem ​​Slave Sie den Job ausführen, müssen Sie ein Projekt mit mehreren Konfigurationen verwenden (andernfalls können Sie keine Slaves auswählen/begrenzen, auf denen Sie den Job ausführen. Es gibt drei Möglichkeiten, dies jedoch zu tun.) Ich habe sie alle ausprobiert (Tie-Plugin funktioniert nur für Master-Jobs. In Advanced Project Options einschränken ist nicht unbedingt ein Trigger für die Triggerung, daher sollten Sie die Slave-Achse verwenden, die heute einwandfrei funktioniert.) 

0
igraczech