O webhook de GitHub non chega ao Jenkins privado: corrixa a ruta

Pode abrir Jenkins pola VPN e aínda así ver que GitHub informa dun webhook fallido, porque son dúas conexións distintas con dous responsables distintos. O navegador viaxa por un túnel que negociou o portátil; o servizo de entrega de GitHub parte de internet pública e non ten ruta cara á rede privada. O acceso ao repositorio non o cambia, aínda que Jenkins poida obter do mesmo repositorio sen problemas. Escolla un punto de entrada, un relé ou a sondaxe, e despois probe a ruta que segue realmente o evento.

Unha sesión de navegador só demostra unha dirección

Unha conexión VPN responde a unha pregunta: pode este portátil chegar ao host interno. A entrega de webhooks pregunta outra: pode un servizo externo abrir unha conexión cara a ese host. Que Jenkins obteña dun repositorio é tráfico de saída e non di nada sobre a accesibilidade entrante. Manteña ambas as direccións en liñas separadas do seu diagrama, incluído que lado inicia cada unha.

Lea o rexistro de entrega antes de cambiar nada. Un tempo de espera esgotado, un restablecemento de conexión e unha solicitude aceptada que non coincidiu con ningunha tarefa teñen tres responsables distintos: rede, proxy e configuración do disparador.

Opción A: expoñer un punto de entrada estreito

Se a organización xa publica un punto de entrada aprobado, expoña a ruta do webhook en lugar do panel. Normalmente iso significa unha regra de proxy inverso que acepta POST no URL do gancho e os reenvía a Jenkins mentres a interface de administración segue inaccesible desde fóra.

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

Execute esa proba desde unha rede sen acceso VPN, porque un éxito desde dentro do túnel non demostra nada. O punto de entrada debería rexeitar as solicitudes sen o segredo compartido, que GitHub envía como cabeceira de sinatura, e aceptar só a única ruta e o único método que publicou. Unha consola de Jenkins pública non é unha solución para o webhook; é un incidente agardando o seguinte escáner. Acote a regra o suficiente para que o resto da aplicación conserve os controis de acceso que tiña.

Opción B: inverter a dirección cun relé

Onde non se aprobará a exposición entrante, un cliente pequeno dentro da rede pode manter unha conexión de saída cara a un relé e recibir os eventos reenviados. O relé pasa entón a formar parte da ruta de entrega, así que a súa dispoñibilidade e autenticación importan tanto como a tarefa de compilación.

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

A guía de Jenkins sobre webhooks detrás de devasas describe esta forma, e paga a pena lela antes de escribir un reenviador propio. Termine o TLS no relé, verifique a sinatura antes de que o evento chegue á tarefa e vixíe a ligazón de saída, porque un túnel caído parece exactamente un evento que nunca se enviou. Confirme tamén que o relé conserva o corpo da solicitude byte a byte, xa que as comprobacións de sinatura fallan con JSON que se analizou e volveu codificar polo camiño.

Opción C: sondar o repositorio

A sondaxe cambia latencia por simplicidade e non necesita ningunha ruta de entrada. Jenkins pode sondar segundo un horario, ou unha tarefa pequena pode consultar a API e iniciar unha compilación cando ve unha revisión descoñecida.

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

Cada sondaxe gasta chamadas á API e engade un atraso entre o push e a compilación, algo que se nota en repositorios concorridos e en límites de velocidade compartidos. Tamén necesita credenciais gardadas onde se execute o sondador, así que limite o token a acceso de só lectura ao repositorio e róteo como calquera outro segredo. Escóllao cando o volume de eventos sexa baixo ou cando nunca se vaia aprobar un punto de entrada, e dígao na descrición da tarefa para que ninguén se pregunte despois por que as compilacións van con atraso.

Acepte unha entrega real, non unha carga de páxina

Escolla a opción que escolla, a proba de aceptación é un evento enviado pola plataforma de orixe, non unha pestana do navegador aberta desde un portátil con privilexios. Faga push dun commit baleiro a unha rama temporal e lea o código de resposta da entrega, o rexistro do relé ou a saída da tarefa de sondaxe, nesa orde. Un 200 do punto de entrada sen compilación significa que o filtro do disparador está mal; un tempo de espera significa que a ruta segue pechada. Anote cal dos tres deseños se usa, porque doutro xeito a seguinte persoa que depure repetirá a proba do navegador e chegará ao mesmo ruela sen saída.

Aplique o mesmo razoamento ás devolucións de pagamento e a outras notificacións externas: cada unha necesita a súa propia ruta cara á aplicación privada, mesmo cando todo o mundo xa ten unha sesión VPN. A ruta de entrega pertence ao deseño da aplicación, non a unha nota ao pé sobre redes.