Multibranch jobs and webhooks

[Steven Foster]

Hi,

Multibranch pipeline jobs do not automatically configure Github webhooks, right?
It's necessary to set up the Jenkins (github plugin) service on the Github repo and add the Jenkins user as a collaborator?

Just wanted to make sure my understanding was correct before I give people the wrong advice.

[Stephen Connolly]

Sigh!

So right now the organisation-level hooks are managed by GHBS plugin

The repository level hooks are managed by the GH plugin and the GHBS plugin has the correct extensions to tell the GH plugin that it needs hooks managed...

Ultimately we want all the hooks managed in the one place, but not there yet...

History: Now as the GH plugin is actively managing the repo-level hooks, we have to delegate to that from the GHBS plugin otherwise the two plugins will end up fighting it out and toggling hooks on and off, hence why the repo level hooks are managed by GH plugin. As the GH plugin doesn't manage organisation levels hooks, in the GHBS plugin we took the "quick" route of managing org level hooks there.

So... what does that mean?

Well what it means is that to have hooks automatically managed at the repo level you need to define the GitHub servers in the global config, enable managing hooks and provide credentials that can manage hooks (note this is the list provided by the GH plugin, not to be confused with the github enterprise servers list in the global config that is provided by the GHBS plugin)

Of course the credentials needed are not the correct type (secret text, should be a GitHub specific credentials type) and none of this is obvious...

And rtyler seems to think that it doesn't work anyway... but *in theory* - right now - that is what you are supposed to do and if you do that it works - at least every time I have tried it!

There are plans to consolidate the servers list and switch from secret text to a GitHub specific credentials type... but that's probably a couple of months given the migration testing that would be required.

HTH

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/935e1006-e2ae-4215-9798-ab5f1e8152cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Sent from my phone

[Steven Foster]

On Friday, September 1, 2017 at 12:18:35 AM UTC+1, Stephen Connolly wrote:

Well what it means is that to have hooks automatically managed at the repo level you need to define the GitHub servers in the global config, enable managing hooks and provide credentials that can manage hooks (note this is the list provided by the GH plugin, not to be confused with the github enterprise servers list in the global config that is provided by the GHBS plugin)

Still lost unfortunately. Perhaps it's only working with the public github? I don't see anywhere in the multibranch configuration to point it towards the Github Servers global configuration.

Just some detail about the setup I'm testing with:

• A private repository under my user in Github enterprise
• Added the Github enterprise server to the Github Servers list in global config
  
• Automatically generated, selected and tested the token using the additional action for my Github user/pass login (and confirmed the token is there in Github)
• Also configured the normal Github Enterprise section in global config
• In the Multibranch Pipeline job, the only Branch Sources available seem to be public Github and the normal Github Enterprise configuration
  

If I choose the Github enterprise option it doesn't seem to configure the webhook (I'm not sure what this would look like in the repo settings on github, but it doesn't respond to pushes)

Maybe something in my setup restricts the Github Server entry from showing as a candidate?

[Stephen Connolly]

So to be clear, if you are using GitHub Enterprise exclusively, you'd have a config something like this:

Yes, I know the same server configured in two different lists

If you are using GitHub cloud *and* GitHub Enterprise you would have a config that looks like this:

(The only difference is that I have added a second GitHub Servers entry for GitHub cloud)

The credentials provided for manage hooks needs to have permission to manage hooks on all repositories.

You may need to trigger the "Re-register hooks for all jobs" if something went wrong.

HTH

--

You received this message because you are subscribed to the Google Groups "Jenkins Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/83a3ca3d-e22d-44e8-a82b-614741c0a7d5%40googlegroups.com.

[Steven Foster]

On Friday, September 1, 2017 at 11:57:32 AM UTC+1, Stephen Connolly wrote:

The credentials provided for manage hooks needs to have permission to manage hooks on all repositories.

You may need to trigger the "Re-register hooks for all jobs" if something went wrong.

HTH

Still struggling with this. I'm continuing testing on a dedicated Jenkins for figuring this out in a small, reproducible way before rolling it out to a user with org-wide permissions.

My repositories are in GitHub enterprise, private under my user (so not an organization). The credential provided to GitHub global config is secret text of a key from my personal user with admin:org_hook, admin:repo_hook, repo permissions.

The credential works with Test Connection.

The credentials given to the multibranch job configuration are my GitHub username and password credentials.

In the Jenkins system log I see "GitHub webhooks activated for job webhook with [] (events: [PULL_REQUEST, PUSH])"

In GitHub I don't see any webhooks set up in the repo settings, and the job doesn't respond to push events.

Going through with a debugger near that log event (GithubPlugin WebhookManager, registerFor) it seems like the repository name is not being mapped from the multibranch job (it's not an SCMTriggerItem). You'll know how this works better than I do, maybe this process is irrelevant and the log event doesn't apply here. Is there anywhere else I can run with a debugger that might help?

[Steven Foster]

Figured out the issue.

In order to manage Webhooks, the branch job must have:
a. run at least once
b. contain at least one scm checkout

In my simple testing neither of those cases were true, leading me to go round in circles for awhile :)
I suspect the request to manage from the branch source plugin will come too early for these conditions to be met.
It might happen eventually (on project re-configuration, or through the "re-register all hooks" button) but it's not too intuitive.

A better way of detecting SCMs than the WorkflowJob getSCMs would be nice, but I do understand the need to cover hugely complex cases where a simple resolution wouldn't apply.
At least now I know, and can come up with workarounds that suit.