Gibt es eine Möglichkeit, GitHub-Webhooks in drei Kategorien zu trennen: Master, Pull-Request und irgendetwas anderes?

9

Was ich versuche zu erreichen, ist die folgende Jobkonfiguration von Jenkins ( Ссылка ):

  1. Haben Sie einen Satz von <project>-master Jobs, die von

    ausgelöst werden
    • Ein Push zum Master-Zweig dieses speziellen Projekts.
    • Manuell, indem Sie auf "Jetzt erstellen"
      • klicken
    • Von einem Skript, das die REST-API verwendet.

    Ich habe dies erreicht, indem ich geeignete refspec angegeben, den GitHub-Webhook usw. hinzugefügt habe. Das war ziemlich einfach.

  2. Haben Sie einen Satz von <project>-pr Jobs, die von

    ausgelöst werden
    • Eine GitHub PR-Erstellung.
    • Ein Kommentar zum PR, der den GitHub Pull Request Builder auslöst.
    • Ein Push in den Zweig, der für bestimmte PR verwendet wurde.

    Ich habe Jenkins die ersten beiden gemacht. Aber ich habe keine Möglichkeit gefunden, das # 3-Objekt aus dieser Liste zu machen, da GitHub-Plugins nicht leicht finden können, ob der Push zu einem PR-Zweig gehört oder nicht. Irgendwelche Ideen wie das gemacht werden kann?

  3. Haben Sie einen Satz von <project>-branch Jobs, die von ANY Push auf ANY-Zweig ausgelöst werden. Problem ist, dass ich Pushs zum Master und zu Zweigen ausschließen möchte, die für PRs verwendet werden. Ich habe Tage lang im Internet nach einer möglichen Lösung gesucht und nichts gefunden, daher wird jeder Hinweis sehr geschätzt.

DejanLekic 24.02.2016, 11:15
quelle

1 Antwort

2
  1. Damit ein Job nur durch Änderungen am Master-Zweig ausgelöst wird, müssen Sie sich nicht mit dem GitHub-Webook anlegen. Sie können einfach den Zweig git plugins branch verwenden, um anzugeben, dass dieser Job nur für den Master-Zweig ausgeführt werden soll.

  2. Wenn Sie einen Job für die Verwendung des Github PUll Request Builder-Plugins als Empfehlung einrichten, wird er nur für einen PR ausgelöst, für die 3 aufgeführten Bedingungen.

  3. der schwierigere .. Soweit ich weiß, gibt es für jenkins keinen einfachen Weg zu wissen, ob eine Verzweigung eine Pull-Anforderung hat oder nicht, da Pull-Anfragen spezifisch für GitHub sind und die jenkins-Verzweigungserkennung nur git verwendet.

Aus meiner Erfahrung habe ich jedoch für diese dritte Option einen <project>-feature Job eingerichtet und ihn so konfiguriert, dass er mit jedem Zweig mit dem Präfix f/ übereinstimmt. Auf diese Weise könnten Entwickler, wenn sie möchten, dass Tests automatisch für ihre Verzweigung ausgeführt werden, aber keine Pull-Anforderung für sie öffnen möchten, einen Zweig wie f/add_a_thing erstellen und Tests auf Pushs automatisch auslösen. Damit dies funktioniert, würde ich den Zweigspezifizierer in der Jobkonfiguration auf f/* setzen.

Alternativ dazu ermöglicht das Git-Plugin einen regulären Ausdrucksparameter für den Zweigspezifizierer. Sie können einen regulären Ausdruck verwenden, um den Master-Zweig gezielt zu ignorieren. Die einzige Möglichkeit, pull-requested-Zweige zu ignorieren, besteht jedoch darin, dass Ihre Entwickler ein Benennungsmuster wie pr/add_a_thing verwenden, um zu erkennen, dass dieser Zweig eine Pull-Anforderung enthält.

    
Jeff 29.02.2016 13:34
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset C ++ spezialisieren ein Lambda für einen bestimmten Typ [duplizieren]