GitHub-webhook når ikkje privat Jenkins: rett opp stigen

Du kan opne Jenkins over VPN og likevel sjå GitHub rapportere ein mislukka webhook, fordi det er to ulike samband med to ulike eigarar. Nettlesaren køyrer på ein tunnel som den berbare forhandla; leveringstenesta til GitHub startar på det opne internettet og har inga rute inn i det private nettet. Tilgang til repositoriet endrar ikkje det, sjølv om Jenkins sjølv kan hente frå same repositorium utan problem. Vel eit inngangspunkt, ein relay eller polling, og test deretter vegen hendinga faktisk tek.

Ei nettlesarøkt provar berre éin retning

Eit VPN-samband svarar på eitt spørsmål: kan denne berbare nå den interne verten. Levering av webhookar spør om noko anna: kan ei ekstern teneste opne eit samband til den verten. At Jenkins hentar frå eit repositorium, er utgåande trafikk og seier ingenting om inngåande tilgjenge. Hald begge retningane på kvar si line i diagrammet ditt, inkludert kva side som startar kvar av dei.

Les leveringsposten før du endrar noko. Ein timeout, eit tilbakestilt samband og ein godteken førespurnad som ikkje samsvarte med nokon jobb har tre ulike eigarar: nettverk, proxy og triggarkonfigurasjon.

Alternativ A: eksponer eit smalt endepunkt

Viss organisasjonen alt publiserer eit godkjent inngangspunkt, eksponer webhook-stigen i staden for dashbordet. Det tyder vanlegvis ein regel for omvend proxy som godtek POST på hook-URL-en og sender dei vidare til Jenkins, medan administrasjonsgrensesnittet blir verande utilgjengeleg utanfrå.

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

Køyr den testen frå eit nettverk utan VPN-tilgang, fordi ein suksess inne frå tunnelen ikkje provar noko. Endepunktet bør avvise førespurnader utan den delte løyndomen, som GitHub sender som signaturheader, og det bør berre godta den eine stigen og metoden du publiserte. Ein offentleg Jenkins-konsoll er ikkje ei webhook-retting; det er ei hending som ventar på neste skannar. Avgrens regelen stramt nok til at resten av applikasjonen held på tilgangskontrollane han hadde.

Alternativ B: snu retninga med ein relay

Der inngåande eksponering ikkje vil bli godkjend, kan ein liten klient inne i nettet halde eit utgåande samband til ein relay og ta imot vidaresende hendingar. Relaysen blir då ein del av leveringsvegen, så tilgjenge og autentisering er like viktig som byggjejobben.

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

Rettleiinga til Jenkins om webhookar bak brannmurar skildrar denne forma, og ho er verd å lese før du skriv din eigen vidaresendar. Avslutt TLS ved relaysen, stadfest signaturen før hendinga når jobben, og overvak den utgåande lenkja, fordi ein broten tunnel ser nøyaktig ut som ei hending som aldri vart send. Stadfest òg at relaysen bevarer kroppen til førespurnaden byte for byte, sidan signaturkontrollar feilar på JSON som er blitt parsa og koda på nytt undervegs.

Alternativ C: poll repositoriet i staden

Polling byter ventetid mot enkelheit og treng ingen inngåande veg i det heile. Jenkins kan polle etter ein tidsplan, eller ein liten jobb kan spørje API-et og starte eit bygg når han ser ein ukjend revisjon.

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

Kvar polling brukar API-kall og legg til ei forseinking mellom push og bygg, noko som blir synleg på travle repositorium og delte hastigheitsgrenser. Det krev òg legitimasjon lagra der pollaren køyrer, så avgrens tokenet til skriveverna tilgang til repositoriet og roter det som kvar annan løyndom. Vel dette når hendingsvolumet er lågt eller når eit inngangspunkt aldri blir godkjent, og seie det i jobbskildringa slik at ingen seinare lurer på kvifor bygga heng etter.

Godta ei ekte levering, ikkje ei sidevising

Uansett kva alternativ du valde, er godtakingstesten ei hending send av kjeldeplattforma, ikkje ei nettlesarfane opna frå ein privilegert berbar. Skyv ein tom commit til ein skrapegrein og les svarkoden til leveringa, loggen til relaysen eller utdata frå pollingjobben, i den rekkjefølgja. Eit 200 frå endepunktet utan eit bygg tyder at triggarfilteret er feil; ein timeout tyder at vegen framleis er stengd. Noter kva av dei tre designa som er i bruk, elles vil den neste som feilsøkjer gjenta nettlesartesten og enda på same blindvegen.

Bruk same resonnementet på betalings-callbacks og andre eksterne varsel: kvart av dei treng si eiga rute inn i den private applikasjonen, sjølv når kvart menneske alt har ei VPN-økt. Leveringsvegen høyrer til i designet av applikasjonen, ikkje i ein nettverksfotnote.