GitHub-Webhook erreicht privates Jenkins nicht: den Pfad reparieren

Sie können Jenkins über das VPN öffnen und trotzdem sehen, wie GitHub einen fehlgeschlagenen Webhook meldet, denn das sind zwei verschiedene Verbindungen mit zwei verschiedenen Eigentümern. Der Browser fährt durch einen Tunnel, den Ihr Laptop ausgehandelt hat; GitHubs Zustelldienst startet im öffentlichen Internet und hat keine Route in das private Netz. Der Zugriff auf das Repository ändert daran nichts, auch wenn Jenkins selbst ohne Probleme aus demselben Repository abrufen kann. Wählen Sie einen Eingang, einen Relay oder Polling, und testen Sie dann den Pfad, den das Ereignis tatsächlich nimmt.

Eine Browsersitzung beweist nur eine Richtung

Eine VPN-Verbindung beantwortet eine Frage: Kann dieser Laptop den internen Host erreichen. Die Webhook-Zustellung fragt etwas anderes: Kann ein externer Dienst eine Verbindung zu diesem Host öffnen. Dass Jenkins ein Repository abruft, ist ausgehender Verkehr und sagt nichts über eingehende Erreichbarkeit. Halten Sie beide Richtungen auf getrennten Linien in Ihrem Diagramm, einschließlich der Seite, die jeweils die Verbindung beginnt.

Lesen Sie den Zustellungsdatensatz, bevor Sie etwas ändern. Ein Timeout, ein Verbindungsabbruch und eine angenommene Anfrage, die zu keinem Job passte, haben drei verschiedene Eigentümer: Netzwerk, Proxy und Trigger-Konfiguration.

Option A: einen schmalen Endpunkt freigeben

Wenn die Organisation bereits einen genehmigten Eingang veröffentlicht, geben Sie den Webhook-Pfad statt des Dashboards frei. Das bedeutet meist eine Reverse-Proxy-Regel, die POSTs auf die Hook-URL annimmt und an Jenkins weiterleitet, während die Administrationsoberfläche von außen unerreichbar bleibt.

curl -sS -o /dev/null -w "%{http_code}\n" -X POST https://jenkins.example.com/github-webhook/

Führen Sie diesen Test aus einem Netz ohne VPN-Zugang aus, denn ein Erfolg aus dem Tunnel heraus beweist nichts. Der Endpunkt sollte Anfragen ohne das gemeinsame Geheimnis ablehnen, das GitHub als Signatur-Header sendet, und nur den einen Pfad und die eine Methode annehmen, die Sie veröffentlicht haben. Eine öffentliche Jenkins-Konsole ist keine Webhook-Lösung; sie ist ein Vorfall, der auf den nächsten Scanner wartet. Fassen Sie die Regel eng genug, dass der Rest der Anwendung die Zugriffskontrollen behält, die sie hatte.

Option B: die Richtung mit einem Relay umkehren

Wo eine eingehende Freigabe nicht genehmigt wird, kann ein kleiner Client im Netz eine ausgehende Verbindung zu einem Relay halten und weitergeleitete Ereignisse empfangen. Der Relay wird dann Teil des Zustellpfads, also sind seine Verfügbarkeit und Authentifizierung genauso wichtig wie der Build-Job.

ssh -N -R 9000:localhost:8080 relay.example.net

Jenkins’ Hinweise zu Webhooks hinter Firewalls beschreiben diese Form, und es lohnt sich, sie zu lesen, bevor Sie einen eigenen Weiterleiter schreiben. Beenden Sie TLS am Relay, prüfen Sie die Signatur, bevor das Ereignis den Job erreicht, und überwachen Sie die ausgehende Verbindung, denn ein abgebrochener Tunnel sieht genauso aus wie ein Ereignis, das nie gesendet wurde. Bestätigen Sie außerdem, dass der Relay den Anfragekörper Byte für Byte erhält, da Signaturprüfungen bei JSON scheitern, das unterwegs geparst und neu kodiert wurde.

Option C: stattdessen das Repository pollen

Polling tauscht Latenz gegen Einfachheit und braucht überhaupt keinen eingehenden Pfad. Jenkins kann nach Zeitplan pollen, oder ein kleiner Job fragt die API ab und startet einen Build, wenn er eine unbekannte Revision sieht.

curl -sS -u "$USER:$TOKEN" "https://api.github.com/repos/OWNER/REPO/commits?per_page=1"

Jedes Polling verbraucht API-Aufrufe und fügt eine Verzögerung zwischen Push und Build hinzu, was bei stark genutzten Repositories und geteilten Ratenlimits sichtbar wird. Es braucht außerdem Anmeldedaten, die dort gespeichert sind, wo der Poller läuft, also begrenzen Sie das Token auf schreibgeschützten Repository-Zugriff und rotieren Sie es wie jedes andere Geheimnis. Wählen Sie das, wenn das Ereignisvolumen niedrig ist oder wenn nie ein Eingang genehmigt wird, und sagen Sie es in der Job-Beschreibung, damit sich später niemand fragt, warum Builds hinterherhinken.

Akzeptieren Sie eine echte Zustellung, keinen Seitenaufruf

Welche Option Sie auch gewählt haben: Der Abnahmetest ist ein Ereignis, das die Quellplattform sendet, kein Browsertab von einem privilegierten Laptop. Pushen Sie einen leeren Commit in einen Wegwerf-Branch und lesen Sie den Antwortcode der Zustellung, das Relay-Log oder die Ausgabe des Polling-Jobs, in dieser Reihenfolge. Eine 200 vom Endpunkt ohne Build bedeutet, dass der Trigger-Filter falsch ist; ein Timeout bedeutet, dass der Pfad noch geschlossen ist. Notieren Sie, welches der drei Designs im Einsatz ist, denn sonst wiederholt die nächste Person bei der Fehlersuche den Browsertest und landet an derselben Sackgasse.

Wenden Sie dieselbe Logik auf Zahlungs-Callbacks und andere Benachrichtigungen von außen an: Jede braucht ihre eigene Route in die private Anwendung, selbst wenn jeder Mensch bereits eine VPN-Sitzung hat. Der Zustellpfad gehört in das Anwendungsdesign, nicht in eine Netzwerk-Fußnote.