Informationen zu Repositorywebhooks
Repositorywebhooks ermöglichen es dir, POST-HTTP-Nutzdaten zu empfangen, wenn bestimmte Ereignisse in einem Repository auftreten. Du kannst die REST-API verwenden, um Repository, Organisation und App-Webhooks zu verwalten. Du kannst Webhookübermittlungen für einen Webhook auflisten oder eine individuelle Übermittlung für einen Webhook abrufen und erneut ausführen, der in eine externe App oder einen Dienst integriert werden kann. Du kannst die REST-API auch verwenden, um die Konfiguration des Webhooks zu ändern. Du kannst beispielsweise die Nutzlast-URL, den Inhaltstyp, die SSL-Überprüfung und das Geheimnis ändern. Weitere Informationen findest du unter:
Wenn du einen einzelnen Webhook einrichten möchtest, um Ereignisse aus allen Repositorys deiner Organisation zu empfangen, findest du in der REST-API-Dokumentation für Organisationswebhooks hilfreiche Informationen.
Zusätzlich zur REST-API kann GitHub auch als PubSubHubbub-Hub für Repositorys fungieren.
Empfangen von Webhooknutzdaten
Damit GitHub Enterprise Server Webhooknutzlasten senden kann, muss ein Zugriff auf deinen Server über das Internet möglich sein. Zudem wird dringend empfohlen, SSL zu verwenden, sodass verschlüsselte Nutzdaten über das HTTPS gesendet werden können.
Webhookheader
GitHub Enterprise Server sendet mehrere HTTP-Header, um zwischen Ereignistypen und Nutzdatenbezeichnern zu unterscheiden. Details findest du unter Webhookheader.
PubSubHubbub
GitHub kann auch als PubSubHubbub-Hub für alle Repositorys fungieren. PSHB ist ein einfaches Veröffentlichungs- bzw. Abonnementprotokoll, mit dem Server registriert werden können, um im Falle einer Aktualisierung eines Themas Updates zu erhalten. Die Updates werden mit einer HTTP POST-Anforderung an eine Rückruf-URL gesendet. Themen-URLs für Pushvorgänge eines GitHub-Repositorys haben das folgende Format:
https://github.com/{owner}/{repo}/events/{event}
Das Ereignis kann ein beliebiges verfügbares Webhookereignis sein. Weitere Informationen findest du unter Webhook-Ereignisse und -Nutzlasten.
Antwortformat
Das Standardformat ist das, was vorhandene post-receive-Hooks erwarten sollten: ein JSON-Textkörper, der als payload-Parameter in einer POST-Anforderung gesendet wird. Du kannst auch angeben, dass der unformatierte JSON-Textkörper entweder mit einem Accept-Header oder einer .json-Erweiterung empfangen wird.
Accept: application/json
https://github.com/{owner}/{repo}/events/push.json
Rückruf-URLs
Rückruf-URLs können das HTTP-Protokoll verwenden.
# Send updates to a PostBin bin
https://www.toptal.com/developers/postbin/123
Abonnieren
Der PubSubHubbub-Endpunkt in GitHub ist http(s)://HOSTNAME/api/v3/hub und übernimmt die folgenden Parameter.
| Name | type | Erforderlich | Beschreibung |
|---|---|---|---|
hub.mode | string | Entweder subscribe oder unsubscribe | |
hub.topic | string | Dies ist der URI des GitHub-Repositorys, das abonniert werden soll. Der Pfad muss das Format /{owner}/{repo}/events/{event} aufweisen. | |
hub.callback | string | Dies ist der URI zum Empfangen der Updates für das Thema. | |
hub.secret | string | Dies ist ein freigegebener geheimer Schlüssel, der eine Hashsignatur des ausgehenden Textinhalts generiert. Du kannst überprüfen, ob ein Push von GitHub stammt, indem du den unformatierten Anforderungstext mit dem Inhalt des X-Hub-Signature- oder X-Hub-Signature-256-Headers vergleichst. In der PubSubHubbub-Dokumentation findest du weitere Details. |
Eine Beispielanforderung mit curl sieht wie folgt aus:
curl -u "user" -i \
http(s)://HOSTNAME/api/v3/hub \
-F "hub.mode=subscribe" \
-F "hub.topic=https://github.com/{owner}/{repo}/events/push" \
-F "hub.callback=https://www.toptal.com/developers/postbin/123"PubSubHubbub-Anforderungen können mehrmals gesendet werden. Wenn der Hook bereits vorhanden ist, wird er der Anforderung entsprechend geändert.