2016-04-18 16 views
6

Wenn es mehr als einen verfügbaren Runner für ein Projekt gibt, wie entscheidet gitlab ci, welcher Runner verwendet werden soll?Wie entscheidet gitlab, welcher Runner für einen Job verwendet wird?

Ich habe eine Omnibus gitlab 8.6.6-ee Installation mit 2 konfigurierten Läufern. Die Läufer sind identisch (Docker Images, Config, etc.), außer dass sie auf verschiedenen Computern laufen.

Wenn sie beide im Leerlauf sind und ein Job kommt, könnte einer von ihnen laufen, welcher wird laufen?

+0

Warum nicht erstellen Test Projizieren und ein paar Builds ausführen? Ich würde mir vorstellen, dass es den ersten verfügbaren Läufer auswählt, und wenn mehrere Läufer im Leerlauf sind, wählt er zufällig. – BrokenBinary

Antwort

2

Um Rubinums Antwort hinzuzufügen, wäre der "erste" Läufer derjenige, der zuerst eincheckt, der alle Kriterien erfüllt. Zum Beispiel könnten Labels festlegen, auf welchen Laufwerken bestimmte Jobs ausgeführt werden.

Die Runner fragen den Gitlab-Server alle X Sekunden ab, um zu prüfen, ob Builds vorhanden sind. Wenn es ein Build Warteschlange gestellt und mehrere Kriterien erfüllen ist, um die erste gewinnt fragen

aktualisieren Kommentare zu beantworten:

Runners kommunizieren über das CI-API http://docs.gitlab.com/ce/ci/api/builds.html zu erhalten Status zu bauen. Dies wird schließlich implizieren, dass es eine mehr oder weniger zufällige Wahl des Läufers basierend darauf wird, wann er den letzten Job beendet hat und die x Menge von ms darauf wartet zu überprüfen.

vollständig Um die Frage zu beantworten:

Kredit geht an BM5k nachdem sie durch den Code zu graben und finden, dass x = 3 Sekunden basierend auf this und this. Auch festgestellt, dass:

, welche Maschine eine Docker + Maschinenläufer wird benutzen, wenn die Läufer ausgewählt wurde) zeigt, dass die machine selection mehr oder weniger (effektiv) zufällig auch

+0

Interessant. Weißt du, wo das im Code passiert? – BM5k

+0

Und um zu verifizieren, dass ich Sie richtig verstehe, sagen Sie, dass der Server nicht wirklich "entscheidet", welcher Runner verwendet wird. Er übergibt nur Jobs an den nächsten Runner, der abfragt (vorausgesetzt, dass der Runner alle Jobanforderungen erfüllt)). – BM5k

+0

Bearbeitete Antwort passend zu den vorherigen Kommentaren. Ich habe nicht gefunden, wo der 'x'amount in den Code gesetzt wird, aber das ist das Projekt, in dem es konfiguriert wird https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/tree/master . –

1

Gitlab CI weist den verfügbaren Laufwerken Aufträge zu. Wenn ein Läufer nicht verfügbar ist, weil er beschäftigt ist, dann vergibt Gitlab CI den Job an andere Läufer, die verfügbar sind. In Ihrem Fall werden die Jobs immer dem ersten Läufer zugewiesen (wer auch immer es ist).

Wenn Sie die Ausführung auf einem bestimmten Läufer/mashine angeben wollen, müssen Sie einen Blick auf meinen Beitrag here.

Meiner Meinung nach seine gute wissen nicht, welche Läufer wird Ihr Build ausführen, wenn Sie Docker, weil das ist verwenden der Vorteil des Läufer/Docker-Archetktur.

+0

aber welcher Läufer ist "erster"? – BM5k

Verwandte Themen