web-dev-qa-db-de.com

Wie kann man verhindern, dass bestimmte Jenkins-Jobs gleichzeitig ausgeführt werden?

Ich habe einige Jobs, die eine gemeinsam genutzte Ressource (Datenbank) verwenden, was manchmal dazu führen kann, dass Builds in dem (seltenen) Fall versagen, dass die Jobs gleichzeitig ausgelöst werden. 

Gibt es bei den Jobs A bis E beispielsweise die Möglichkeit, A und C niemals gleichzeitig auszuführen ?

Abgesehen von der zuvor genannten Ressource sind die Builds unabhängig voneinander (nicht z. B. in einer Upstream-/Downstream-Beziehung).

Ein "Brute-Force" -Verfahren würde die Anzahl der Executoren auf einen beschränken, aber dies ist offensichtlich weniger als ideal, wenn die meisten Jobs gleichzeitig ausgeführt werden könnten und auf dem Build-Server keine Rechenressourcen fehlen.

58
Jonik

Es gibt derzeit zwei Möglichkeiten, dies zu tun:

  • Verwenden Sie das Throttle Concurrent Builds plugin.
  • Richten Sie diese Jobs so ein, dass sie auf einem Slave ausgeführt werden, der nur einen Executor hat.
37
sti

Das Locks and Latches Plugin hier sollte helfen.

Diese Frage ist wahrscheinlich ein Betrug von Wie stelle ich sicher, dass in Hudson nur eine bestimmte Jobkategorie gleichzeitig ausgeführt wird?

13
pwan

Das ist eine alte Frage, aber das Thema kann immer noch relevant sein, insbesondere wenn Anwendungstests auf Jenkins ausgeführt werden.

Mit dem Lockable Resources Plugin können Sie sperrbare Ressourcen definieren, die von Builds verwendet werden können. Wenn für Ihren Build eine Ressource erforderlich ist, wird die Sperre ausgeführt. Wenn für einen zweiten Build dieselbe Ressource erforderlich ist (die dann bereits gesperrt ist), wird sie in die Warteschlange gestellt, damit die Ressource frei ist.

Obwohl die Dokumente Computer oder Drucker als Beispiele für sperrbare Ressourcen verwenden, sollte das Datenbankbeispiel von oben ebenfalls funktionieren.

Im Gegensatz zu dem in den Antworten von 2012 erwähnten Locks und Latches Plugin scheint dieses Paket derzeit gepflegt zu sein (derzeit ~ 2016).

3

Schauen Sie sich das External Resource Dispatcher Jenkins-Plugin an, das im November 2012 erstmals veröffentlicht wurde. Dieses (relativ) neue Plugin scheint diesen Anwendungsfall genau abzudecken.

2
Marnix Klooster

N.B. Sie benötigen keine physische oder virtuelle Hardware für einen Slave/Knoten. Sie können "Slaves" einrichten, die auf dem Master-Server ausgeführt werden.

Jenkins verwalten> Knoten verwalten> Neuer Knoten 

und machen Sie einen "dummen Sklaven" mit jeweils einem eigenen Stammverzeichnis.

Erstellen Sie einige Slaves, führen Sie sie aus, wenn der Server startet, und Sie haben im Wesentlichen Pools von Executoren angelegt.

Sie könnten sagen, ...

db - nur ein Executor in Ihrem Fall . compile - beschränken Sie sich auf Hardware oder Anzahl der CPUs . - Skripts - Sie haben viele Executoren für all diese kleinen Aufgaben, die Jenkins gut kann.

0
teknopaul

Alte Frage, und ob dies für Ihre Bewerbung funktioniert, kann ich nicht genau sagen, da Sie keine Einzelheiten zu Ihrer Bewerbung angegeben haben. Ich wollte jedoch die Art und Weise hinzufügen, wie ich dies in unserer Rails-Anwendungstestsuite behandelt habe. 

Die Datenbankkonfiguration unserer Anwendung (database.yml) befindet sich nicht im Quell-Repository. Stattdessen lebt es in /var/lib/configs/uniquing_database.yml auf dem VM, auf dem unsere Jenkins-Instanz ausgeführt wird. 

Einer der Schritte unseres Erstellungsprozesses umfasst das Kopieren dieser Konfigurationsdatei in den Projektarbeitsbereich: 

cp /var/lib/jenkins/configs/myapp_unique_database.yml config/database.yml

und diese Konfiguration berücksichtigt die von Jenkins für die Umgebung zur Verfügung gestellten Informationen zu Arbeitsbereich und Build-Nummer, um eine eindeutig benannte Datenbank für diesen Job und seine spezifische Ausführung zu erstellen: 

test:
  adapter: postgresql
  encoding: unicode
  Host: 127.0.0.1
  port: 5432
  database: myapp_test<%= ENV['JOB_NAME'].split('/').last %><%= ENV['BUILD_NUMBER'] %>

Der Rest unseres Builds wird ohne Wissen oder Sorgfalt ausgeführt, dass er in einer separaten Datenbank ausgeführt wird. Schließlich stellen wir am Ende unseres Builds sicher, dass diese Datenbank gelöscht wird, sodass keine Testdatenbanken vorhanden sind, die das Dateisystem schädigen: 

Rails_ENV=test bundle exec rake db:drop
0
Yoopergeek