Momentan unterstützt Buildbot nicht mehrere Repositories. Wenn man dies haben möchte, müssen separate Instanzen von Buildbot ausgeführt werden.
Ich bin immer noch neugierig, ob jemand einen kreativen Workaround gefunden hat, um diese Funktion trotzdem funktionieren zu lassen.
Diese Antwort hat kürzlich einige downvotes erhalten. Bitte beachtet, dass diese Antwort auf die Versionen von buildbot zutrifft, die Ende 2012 / Anfang 2013 veröffentlicht / verwendet wurden und möglicherweise nicht für zukünftige Versionen verwendet werden können.
Wie @Macke gesagt hat, unterstützt buildbot (& gt; = 0.8.x) mehrere Projekte / Repositories. Dies geschieht mit der folgenden Konfiguration:
%Vor% Sie können sehen, dass der Parameter project in der Änderungsquelle dann erneut in der Eigenschaft change_filter des Schedulers verwendet wird, um sicherzustellen, dass der Scheduler nur auf diese bestimmte Änderungsquelle reagiert. Auf diese Weise können Sie mehrere Änderungsquellen und mehrere Scheduler konfigurieren, die auf explizit ausgewählte Änderungsquellen reagieren.
Tatsächlich bekomme ich nicht den Grund, warum Sie sagen, dass es mehrere Repositories nicht unterstützt .... Sie können für jedes Repository und mehrere Scheduler einen Poller erstellen, der die verschiedenen Poller anpingt und die Builds für viele verschiedene Repositories ( entweder auf demselben Computer, auf dem der Master läuft, oder Sie können einen dedizierten Slave auf einer anderen Box haben.)
Sie möchten vermeiden, dass mehrere Instanzen vorhanden sind, aber zum Beispiel Master und Slave auf demselben Rechner existieren, selbst wenn es ein Problem ist, sie in der richtigen Reihenfolge zu starten und zu stoppen, andernfalls erhalten Sie Konfliktfehler:)
| & gt; Momentan unterstützt Buildbot nicht mehrere Repositories.
Ich verstehe die Frage nicht wirklich .. Entschuldigung. Meinen Sie, dass Sie mehrere Master-Server ausführen müssen? Eigentlich wird das von den buildbot devs empfohlen, aber das Gegenteil funktioniert für mich: Du kannst in den gleichen master.cfg mehrere Slaves (Spalten im Wasserfall) haben und für jeden oder einen BuildFactory mit verschiedenen ersten Schritten von der Typ: Git(repourl=...) und / oder Mercurial(repourl=...) etc.
Jeder klont / zieht aus verschiedenen Repositories und Sie können sogar weitere Checkouts hinzufügen, die in den folgenden Schritten benötigt werden (mit maven oder direkt mit Ihrem scm-Client). Das einzige Problem mit einer eindeutigen master.cfg -Datei ist, dass alle Builder nur eine Methode haben, um Benachrichtigungen über Änderungen zu erhalten. Wir haben zum Beispiel PBChangeSource() (Master wird vom Remote-Code benachrichtigt, es hat nichts zu tun). Wenn Sie zum Beispiel einen SCM mit guter PBChangeSource-Unterstützung (zB svn, hg, git) und einen anderen mit schlechter Unterstützung (zB MKS) haben, sollten Sie zwei Master-Server-Instanzen haben, um das zu bewältigen.
Ich hoffe, es wird dir helfen.
Tags und Links buildbot