Wie verarbeiten github webhook Nutzlast in Jenkins?
Ich bin derzeit auslösen meiner Jenkins-builds über einen GitHub webhook. Wie würde ich das Parsen der JSON-payload? Wenn ich versuche, Sie zu parametrisieren mein build und verwenden Sie die $variable payload, die GitHub webhook schlägt fehl mit der folgenden Fehlermeldung:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>Error 400 This page expects a form submission</title>
</head>
<body><h2>HTTP ERROR 400</h2>
<p>Problem accessing /job/Jumph-CycleTest/build. Reason:
<pre> This page expects a form submission</pre></p><hr /><i><small>Powered by Jetty://</small></i><br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
</body>
</html>
Wie kann ich mein GitHub webhook arbeiten mit einer parametrisierten Jenkins bauen, und wie könnte ich dann analysieren und die webhook Nutzlast für die Nutzung bestimmter Linien, wie die Benutzernamen der committer, als Bedingungen in den bauen?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Gibt es ein paar tricks, um diese zu arbeiten, und ich fand das (jetzt aufgelöste)
chloky.com
blog-post, um nützlich zu sein für die meisten. Da es klingt wie Sie habe die webhook die Kommunikation mit Ihren Jenkins-Instanz zumindest, ich ' ll überspringen diese Schritte für jetzt. Aber, wenn Sie wollen mehr Details, Blättern Sie über das Ende meiner Antwort zu sehen, die Inhalte, die ich in der Lage war, um zu retten, vonchloky.com
- ich weiß nicht, der ursprüngliche Autor und die information könnte veraltet sein, aber ich fand es hilfreich.Also zusammenfassen, können Sie das folgende tun, um deal mit der Nutzlast:
Einrichten der webhook in github zu verwenden, die buildWithParameters Endpunkt statt des bauen Endpunkt, d.h.
http://<<yourserver>>/job/<<yourjob>>/buildWithParameters?token=<<yourtoken>>
Konfigurieren Sie Ihre webhook zu verwenden application/x-www-form-encoded statt application/json. Der erste Ansatz packt die JSON-Daten in einem Formular variable, genannt "payload", das ist vermutlich wie Jenkins können, weisen Sie auf eine Umgebungsvariable. Die application/json Ansatz nur Beiträge rohen JSON, das scheint nicht zu sein, abbildbar zu nichts (ich konnte es nicht zu arbeiten). Sie können den Unterschied sehen, indem Sie Ihre webhook zu so etwas wie requestbin und überprüfung der Ergebnisse.
Hoffe, das hilft!
BEARBEITEN hier ist, was ich greifen konnte aus der ursprünglichen blog-posts auf
http://chloky.com/tag/jenkins/
, die schon tot für eine Weile.Hoffentlich wird dieser Inhalt ist auch nützlich für jemanden.
Post #1 - Juli 2012
Github bietet eine schöne Möglichkeit, um das Feuer aus Benachrichtigungen an ein CI-system wie jenkins, wenn ein commit gemacht wird gegen ein endlager. Das ist wirklich nützlich für die Auftakt-build-jobs in jenkins zu testen, die verpflichtet wurden, nur auf der repo. Sie müssen einfach gehen Sie zum Abschnitt administration des Repositorys, klicken Sie auf den Dienst, die Haken auf der linken Seite, klicken Sie auf "webhook URLs' oben auf der Liste, und geben Sie dann die URL der webhook, dass jenkins erwartet wird (Blick auf das jenkins-plugin für die Einrichtung jenkins zu erhalten, diese Haken aus github).
Vor kurzem, obwohl, ich war auf der Suche nach einem Weg, um ein webhook Feuer, wenn Sie einen pull-request gemacht wird, gegen ein repo, eher als wenn ein commit gemacht wird, um die repo. Dies ist so, dass wir jenkins laufen eine Reihe von tests auf die pull-Anforderung, bevor Sie entscheiden, ob die Zusammenführung der pull-request in – nützlich, wenn Sie haben eine Menge Entwickler, die Ihre eigenen Gabeln und regelmäßig Einreichen pull-Anfragen an die main-repo.
Es stellt sich heraus, dass dies nicht so offensichtlich, als würde man hoffen, und erfordert ein wenig über Unordnung mit der github API.
Standardmäßig, wenn Sie konfigurieren einen github webhook, es ist so konfiguriert, dass nur ausgelöst wird, wenn ein commit gemacht wird, gegen repo. Es gibt keinen einfachen Weg, um zu sehen, oder zu ändern, diese in den github web-Schnittstelle, wenn Sie die webhook. Zur Manipulation der webhook in irgendeiner Weise, die Sie brauchen, um die API verwenden.
Änderungen auf eine repo über die github-API, müssen wir ermächtigen uns selbst. Wir sind curl verwenden, so dass, wenn wir wollten, könnten wir übergeben den Benutzernamen und das Kennwort jedes mal, wie das ist:
Oder, und dies ist eine viel bessere option, wenn Sie möchten Skript jede von diesem Zeug, und wir können Sie schnappen Sie sich ein oauth-token und verwenden Sie es in nachfolgenden Anfragen zu ersparen, halten die Eingabe unseres Passwortes. Dies ist, was wir tun, in unserem Beispiel. Als erstes benötigen wir zum erstellen eines oauth-Autorisierung und schnappen Sie sich den token:
Werden Sie zurückgegeben, so etwas wie die folgenden:
Nun können wir dieses token verwenden, in der die nachfolgenden Anforderungen für die Bearbeitung unserer github-account über die API. Also lasst uns Fragen zu unserer repo und finden Sie die webhook wir in das web-interface früher:
Beachten Sie die wichtigen Bits aus, dass die json-Ausgabe:
Diese im Grunde sagt, dass diese webhook wird nur ausgelöst, wenn ein commit (push) ist aus dem repo. Die github-API-Dokumentation beschreibt zahlreiche unterschiedliche event-Typen, können zu dieser Liste Hinzugefügt werden, für unsere Zwecke, die wir hinzufügen möchten pull_request, und dies ist, wie wir es tun (beachten Sie, dass wir die id des webhook aus der json-Ausgabe vor. Wenn Sie mehrere Haken definiert die Ausgabe enthält alle diese Haken so sicher sein, um die richtige ID):
Sehen!
Diesem webhook wird jetzt auch ausgelöst werden, wenn entweder eine commit-ODER einen pull-request gemacht wird, gegen unsere repo. Genau das, was Sie tun, in Ihrem jenkins/mit diesem webhook ist bis zu Ihnen. Wir verwenden es zum Auftakt eine Reihe von Integrations-tests in jenkins zum test der vorgeschlagenen patch, und dann auch tatsächlich Zusammenführen und schließen Sie (erneut unter Verwendung der API), der pull-request automatisch. Ziemlich süß.
Post #2 - September 2012
In einem früheren Beitrag Sprach ich über das konfigurieren der github webhook das Feuer auf eine pull-Anforderung, nicht nur für einen commit. Wie bereits erwähnt, gibt es viele Ereignisse, die geschehen, in einem github-repo, und wie pro die github Dokumentation, eine Menge von diesen kann verwendet werden, um auszulösen, die webhook.
Unabhängig davon, welches Ereignis Sie sich entscheiden, trigger auf, wenn der webhook feuert von github, es stellt im wesentlichen einen BEITRAG zu der URL konfiguriert werden, in dem webhook, einschließlich einer json-Nutzlast in den Körper. Die json-Nutzlast enthält verschiedene details über das Ereignis, durch das die webhook Feuer. Ein Beispiel Nutzlast, feuerte auf eine einfache Begehen können, sehen Sie hier:
Diese ganze Nutzlast übergeben bekommt in die POST-requests als einzigen parameter, mit dem fantasievollen Titel
payload
. Es enthält eine Menge von Informationen über das Ereignis, das gerade passiert ist, die alle oder von denen jeder verwendet werden kann, von jenkins, wenn wir bauen Arbeitsplätze nach dem trigger. Um diese Nutzlast in Jenkins, wir haben ein paar Optionen. Diskutiere ich unten.Bekommen die $payload
In jenkins, die beim erstellen eines neuen build-job, wir haben die Möglichkeit, unter Angabe der Namen der Parameter, die wir erwarten, zu passieren, um den job in der POST, löst die bauen. In diesem Fall würden wir einen einzigen parameter
payload
, wie hier zu sehen:Übergabe von Parametern an einen jenkins build job
Weiter unten in der job-Konfiguration, können wir bestimmen, wir würden gerne in der Lage sein, um die trigger-build Remote (ie. wollen wir zulassen github zum auslösen des build durch die Veröffentlichung unserer URL mit der Nutzlast):
Dann, wenn wir die webhook in unserem github repo (wie beschrieben im ersten post) geben wir die URL, die jenkins sagt uns zu:
Können Sie nicht sehen, Sie alle in den screencap, aber die URL die ich angegeben für den webhook war der eine, jenkins sagte mir:
http://jenkins-server.chloky.com:8080/job/mytestbuild//buildWithParameters?token=asecuretoken
Wenn ich jetzt gebaut meinen neuen job in jenkins, für die Zwecke dieses Tests habe ich einfach gesagt es auf echo den Inhalt der 'Nutzlast' - parameter (welcher in paramterized baut, wie eine shell-variable mit dem gleichen Namen), mit einem einfachen Skript:
Jetzt zum testen die ganze Sache, die wir einfach machen müssen, sich verpflichten, unsere repo, und dann pop über jenkins zu suchen, um den job ausgelöst wurde:
Und über in unseren jenkins-server, können wir die Konsolen-Ausgabe von der job, der ausgelöst wurde, und lo und siehe, es ist unser 'payload', enthalten in der $payload variabel und für uns verfügbar zu konsumieren:
So toll, alle die Infos über unsere github-Ereignis ist hier. und voll in unser jenkins-job! Es ist wahr, es ist in einer großen json-blob, aber mit ein bisschen schlauer bash-Sie sollten gut zu gehen.
Natürlich ist dieses Beispiel verwendet eine einfache verpflichten zu demonstrieren, die Prinzipien immer auf die Nutzlast innerhalb jenkins. Wie wir diskutiert in der früheren post, ein Begehen ist nur eine von vielen Veranstaltungen, die auf eine repo, die können, trigger ein webhook. Was Sie tun in jenkins sobald Sie ausgelöst werden, ist bis zu Ihnen, aber der Reale Spaß kommt, wenn Sie beginnen die Interaktion mit github zu weiteren Aktionen auf die repo (Kommentare, merge pull-Anforderungen, die übertragungen verwirft, etc) basierend auf den Ergebnissen Ihrer build-jobs bekam, ausgelöst durch die Initiale Ereignis.
Ausschau nach einem späteren post, wo ich binden Sie es alle zusammen und zeigen Ihnen, wie zu Bearbeiten, führen Sie tests, und schließlich führen Sie eine pull-Anfrage, wenn erfolgreich – alle automatisch innerhalb jenkins. Automatisierung macht Spaß!
Es ist ein Generic Trigger Webhook plugin, die dazu beitragen können Werte aus dem post-Inhalt zu bauen.
Wenn die post Inhalt:
Können Sie konfigurieren es wie folgt:
Und beim auslösen mit einigen nach Inhalt:
Es wird resolv Variablen und machen Sie in der build-job.