[JENKINS-55949] Arrange RSS (or something like it) as a transport for GitHub webhooks

In our company, the Jenkins master is in a private network, and while the corporate security permits it to initiate connections to the internet to download updates, artifacts, etc. it may not receive any connections. We evaluated some tunneling services, so the Github hook URL would be set to that service endpoint and pop out inside the perimeter as a POST to our jenkins, but even that was not permitted.

So the next reasonable option would be to have a Jenkins master keep a persistent connection to some web service on the internet, perhaps an RSS source, and receive lines equivalent to webhook payloads over that transport. So here the question is two-fold:

• extend the webhook support to not only receive POSTs, but be able to instead persistently connect somewhere and receive hooks there;


• provide a service that would produce the RSS feed like that. Two most reasonable places that come to mind would be either arranging with GitHub that they provide such a service, probably as part of the REST API so it can be tied to logins, organizations and repos in question, or having Cloudbees host a retranslator that would receive hooks from Github and feed them over this service, with Jenkins masters all over the world connecting to the retranslator with some unique IDs (that they set up in the webhook on Github side)


• also to consider, this might be a more generic problem than just for github, since there are many other supported SCM types and SCM service providers, so maybe a coordinated solution higher in the stack would be the more reasonable choice.

---
Originally reported by jimklimov, imported from: Arrange RSS (or something like it) as a transport for GitHub webhooks

• status: Open
  
• priority: Minor
  
• component(s): github-branch-source-plugin
  
• resolution: Unresolved
  
• votes: 0
  
• watchers: 2
  
• imported: 2025-12-02
  

Raw content of original issue

In our company, the Jenkins master is in a private network, and while the corporate security permits it to initiate connections to the internet to download updates, artifacts, etc. it may not receive any connections. We evaluated some tunneling services, so the Github hook URL would be set to that service endpoint and pop out inside the perimeter as a POST to our jenkins, but even that was not permitted.


So the next reasonable option would be to have a Jenkins master keep a persistent connection to some web service on the internet, perhaps an RSS source, and receive lines equivalent to webhook payloads over that transport. So here the question is two-fold:



	
extend the webhook support to not only receive POSTs, but be able to instead persistently connect somewhere and receive hooks there;

	
provide a service that would produce the RSS feed like that. Two most reasonable places that come to mind would be either arranging with GitHub that they provide such a service, probably as part of the REST API so it can be tied to logins, organizations and repos in question, or having Cloudbees host a retranslator that would receive hooks from Github and feed them over this service, with Jenkins masters all over the world connecting to the retranslator with some unique IDs (that they set up in the webhook on Github side)

	
also to consider, this might be a more generic problem than just for github, since there are many other supported SCM types and SCM service providers, so maybe a coordinated solution higher in the stack would be the more reasonable choice.

Commencez par examiner la prise en charge existante des webhooks de github-branch-source-plugin et la manière dont Jenkins reçoit les événements SCM. L’issue ne nomme aucun fichier ni test ; sa réalisation nécessiterait de décider quel transport sortant persistant utiliser, de définir le service qui le fournit et de déterminer si la solution relève de ce plugin ou d’un composant Jenkins de niveau supérieur.

Rédigé par le modèle d'indexation à partir du texte de l'issue.