-
Notifications
You must be signed in to change notification settings - Fork 400
Allow registering as a webhook instead of the GitHub Jenkins Service #53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This plugin not about PRs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, failed on the event(I was also working on a separate plugin). I'll fix that.
|
Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests |
|
Fixed the event and since this is not using the Jenkins github service, we need to react accordingly to github's ping events. |
|
If you don't want to use automanaged hook, then you can specify "manage hook manually" in global configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So what is the difference between this two hooks then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main and most important difference is that you're allowed to register more than one Jenkins instance on the same repository, something that using the "jenkins" hook does not allow.
|
I will try understand your use case again, but it looks like you are trying to integrate gh plugin with other requirements in a wrong way. I'm working on searching way of providing some APIs for gh related plugin for working with gh hooks, maybe it will help you. I will let you know when i found some solution. |
|
Also, I do want to use the auto-managed hook feature. I don't want to register the hooks by hand. |
|
The use case is 3 Jenkins instances that need to be triggered from the same repository, and, since only switching the way hooks are registered allows the same user experience, I felt that adding a flag to switch the register behavior is better than creating a duplicate plugin for which the only difference is the way hooks are registered. |
|
IMO just third choice "don't manage hooks" should be right |
|
Problem that service is limited only to one jenkins is GH issue. I will try check myself and then try to get answer from their support. |
|
Don't manage hooks requires you to add hooks by hand on the GitHub UI. Not optimal, and this ain't that drastic of a change. But I'll wait for your findings. |
|
That means that solution provided by github is bad and need to be extended/resolved. |
|
Yes, but does the github hook apps allow multiple registrations from the base? Or is this just an issue with the Jenkins github hook app? |
|
Either way, this solves the immediate problem. |
|
According to documentations services are single instances. I sent email to github support to get some information how they see their feature for end-users. If it deprecated feature, then it makes sense to not using services and describe github hooks configuration in documentation. |
|
Support said they doesn't plan extending services and they doesn't accept service templates anymore. It makes sense to migrate plugin to using plain hooks. I'm thinking how it better can be done. |
|
OK. Its probably best to add some documentation to the plugin about the move and eventually ask GitHub to remove the service a few versions down the road to allow for users to migrate to a newer plugin version. |
|
You still can use "service" from gh UI, it just a hardcode of "jenkins" + "push". Hook managment is internal, if you choosed "manage manually" then no changes required. Only automanage, but automanaged hooks can be easily upgraded from service -> webhooks :) |
|
If you register 3 separate applications (in GitHub) and give each Jenkins separate application credentials then your three separate instances will register hooks for each. You can't make use of the Jenkins service integration with multiple instances if you're only using one application. Generate new app codes for each. |
|
I am using one application per Jenkins. But a repository can only have a single Jenkins service integration at a time, independent of the applications... Last time I checked... |
|
Ah then might want to check again. I accidentally registered two applications using different API tokens and the service duplicated registration. I had regenerated the token because I forgot it. |
|
Though to be clear I still think it's useful to provide registering as webhooks automatically. I only piped up with a workaround for you in the mean time. |
|
Please try 1.12.0 |
Refs https://issues.jenkins-ci.org/browse/JENKINS-27842