Skip to content

Conversation

@s0undt3ch
Copy link

Copy link
Member

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

Copy link
Author

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.

@jenkinsadmin
Copy link
Member

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests

@s0undt3ch
Copy link
Author

Fixed the event and since this is not using the Jenkins github service, we need to react accordingly to github's ping events.

@KostyaSha
Copy link
Member

If you don't want to use automanaged hook, then you can specify "manage hook manually" in global configuration.

Copy link
Member

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?

Copy link
Author

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.

@KostyaSha
Copy link
Member

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.

@s0undt3ch
Copy link
Author

Also, I do want to use the auto-managed hook feature. I don't want to register the hooks by hand.

@s0undt3ch
Copy link
Author

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.

@KostyaSha
Copy link
Member

IMO just third choice "don't manage hooks" should be right

@KostyaSha
Copy link
Member

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.

@s0undt3ch
Copy link
Author

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.

@KostyaSha
Copy link
Member

That means that solution provided by github is bad and need to be extended/resolved.

@s0undt3ch
Copy link
Author

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?

@s0undt3ch
Copy link
Author

Either way, this solves the immediate problem.

@KostyaSha
Copy link
Member

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.

@KostyaSha
Copy link
Member

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.

@s0undt3ch
Copy link
Author

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.

@KostyaSha
Copy link
Member

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 :)

@samrocketman
Copy link
Member

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.

@s0undt3ch
Copy link
Author

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...

@samrocketman
Copy link
Member

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.

@samrocketman
Copy link
Member

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.

@KostyaSha
Copy link
Member

Please try 1.12.0

@KostyaSha KostyaSha closed this Jul 22, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants