Two separate GitHub Organizations used with same GitHub Branch Source Plugin configuration results in only one job getting triggered per PR

[Ian Vernon]

I had asked previously about getting two jobs triggered from GitHub when a PR is opened. Each job uses a distinct Jenkinsfile. This is so multiple sets of tests can be triggered as separate jobs when a PR is opened. That thread can be found here: https://groups.google.com/forum/#!topic/jenkinsci-users/RXZykkWy8PQ . I was able to get it set up, but the behavior isn't exactly what I want. I have looked all over for how to fix this :(

However, it appears that the GitHub Organization configuration for each job must be different for me to achieve having two jobs appear on GitHub that are linked to Jenkins. The configuration of the GitHub Organization that runs the first job is attached as 'jenkins1_config.png'. This is set up using the GitHub Branch Source Plugin.

The fields that are in play here are the following. For both jobs, I want the following configuration:

* Discover Branches

  Strategy: Exclude Branches that are also filed as PRs

* Discover Pull Requests from Origin

  Strategy: The current pull request revision

In order for the second organization's job to appear in GitHub, I have to change these two options. If the configuration is the same, it doesn't even show up, and only the first job shows up on GitHub. How can I get the same behavior for each GitHub Organization on Jenkins so that it appears on GitHub?

One thing I have noticed is that it seems like it is not possible to change the names of these jobs on a per-GitHub organization basis, and that this is only configurable via global Jenkins configuration. Attached is the configuration for the GitHub Pull Request Builder that we have set up for that Jenkins instance as 'ghprb_configuration.png'. 

Please let me know if I need to provide more information. Thanks!

[Stephen Connolly]

On Thu 4 Jan 2018 at 18:11, Ian Vernon <ianve...@gmail.com> wrote:

I had asked previously about getting two jobs triggered from GitHub when a PR is opened. Each job uses a distinct Jenkinsfile. This is so multiple sets of tests can be triggered as separate jobs when a PR is opened. That thread can be found here: https://groups.google.com/forum/#!topic/jenkinsci-users/RXZykkWy8PQ . I was able to get it set up, but the behavior isn't exactly what I want. I have looked all over for how to fix this :(

However, it appears that the GitHub Organization configuration for each job must be different for me to achieve having two jobs appear on GitHub that are linked to Jenkins. The configuration of the GitHub Organization that runs the first job is attached as 'jenkins1_config.png'. This is set up using the GitHub Branch Source Plugin.

The fields that are in play here are the following. For both jobs, I want the following configuration:

* Discover Branches

  Strategy: Exclude Branches that are also filed as PRs

* Discover Pull Requests from Origin

  Strategy: The current pull request revision

In order for the second organization's job to appear in GitHub, I have to change these two options. If the configuration is the same, it doesn't even show up, and only the first job shows up on GitHub. How can I get the same behavior for each GitHub Organization on Jenkins so that it appears on GitHub?

What do you mean “appears on GitHub”? Do you mean as a second status check mark?

You may want to use a custom notifications context if that is the case. There’s a plugin Steve F wrote that uses a new extension point in GitHub Branch Source (look at the changelog and you might be able to find it mentioned... or maybe Steve will chime in)

One thing I have noticed is that it seems like it is not possible to change the names of these jobs on a per-GitHub organization basis, and that this is only configurable via global Jenkins configuration. Attached is the configuration for the GitHub Pull Request Builder

FYI: This plugin is completely ignored by multibranch.

that we have set up for that Jenkins instance as 'ghprb_configuration.png'. 

Please let me know if I need to provide more information. Thanks!

--
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/c8a800c6-2a7a-4ad3-a3cb-fa6fa7940568%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Sent from my phone

[Ian Vernon]

> What do you mean “appears on GitHub”? Do you mean as a second status check mark?

Yes, that is correct. Only one check mark appears despite there being two GitHub Organizations set up. If I change the aforementioned settings, two check marks appear on GitHub, but I want to have the same behavior with the plugin. 

 > FYI: This plugin is completely ignored by multibranch.

Is a GitHub Organization multibranch? 

Regarding the custom notification context, is this what you are referring to? https://issues.jenkins-ci.org/browse/JENKINS-36574

Thanks for the quick reply!

[Steven Foster]

Here is the repo for the custom github context plugin https://github.com/steven-foster/github-scm-trait-notification-context

I still need to actually release it to the plugin center, hopefully that's not too arduous.

It lets you specify a context label for a multibranch project's github notifications. If github receives a duplicate context label it just replaces the existing one, so this is helpful if you are doing more than one kind of build for a repo.

[Ian Vernon]

I'll hold off until it is released to the plugin center before downloading it.

>  If github receives a duplicate context label it just replaces the existing one, so this is helpful if you are doing more than one kind of build for a repo.

That explains it! That's so frustrating :( . Thanks for your help!

[Steven Foster]

finally figured out the release process so hopefully the custom notification plugin should be available soon

[Anthony Lamping]

Any chance this will be made to be used from a scripted pipeline?