-
Bug
-
Resolution: Unresolved
-
Minor
-
None
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.
- relates to
-
JENKINS-41072 Poll the GitHub Events API as an alternative to webhook
-
- Open
-
-
JENKINS-55993 Arrange GitHub email notifications support as an alternative transport for webhooks
-
- Open
-
I've contacted GitHub support, whether they can extend existing webhook and email notifications with such a transport that "private" CI systems can connect to, and the person who got the message said it makes sense and the idea would be forwarded to developers.
Bonus take-away from the research: there are "email notifications" which have now been standardized as an alternative to webhooks. So if a private Jenkins instance had a plugin to read those from a corporate mail server and react like for web hooks, it is yet another approach better than occasional full-sweep SCM Polling - this particular idea is tracked in JENKINS-55993.