Unfortunately, I can't duplicate the problem. I created a Multibranch Pipeline using https://bitbucket.org/markewaite/jenkins-bugs/src/master/ as the Bitbucket repository and using Bitbucket branch source cloning the repository over https. The repository is not a fork and has two pull requests. When I configure the Multibranch Pipeline job to 'Exclude branches that are also filed as PRs', it correctly excludes the two branches that are also filed as pull requests. When I switch it to include only branches that are filed as PRs, it also behaves as expected.
Sorry, I don't have other ideas to offer. If you'd like to perform a detailed comparison between your configuration and mine, I'd be willing to temporarily grant you access to my Jenkins server. Send me a private e-mail if you'd like that access. Mark Waite On Mon, Apr 1, 2019 at 2:56 PM Tom Duerr wrote: > Hi, > > Ive updated core Jenkins to 2.150.3 and updated quite a few of the > pipeline plugins. > Here is the current list: > https://pastebin.com/Maf6iuvQ > > We're still getting two PRs for each PR created from the origin and not a > fork. > > I was going to try Slide's advice about filtering on branches but now that > config option > indicates that its been deprecated. Not sure where to configure the "Named > Branch" plugin. > https://imgur.com/a/smnC98S > > > Other thoughts? > > Thanks, > Tom > > > On Friday, March 29, 2019 at 10:55:04 AM UTC-7, Tom Duerr wrote: >> >> I will update the pipleline related plugins this weekend and maybe >> upgrade Jenkins (currently at 2.138 ). >> I will report back with results. >> >> Thanks for the help. >> >> On Thu, Mar 28, 2019 at 5:29 PM Mark Waite wrote: >> >>> >>> >>> On Thu, Mar 28, 2019 at 6:22 PM Tom Duerr wrote: >>> >>>> Mark, >>>> The issue only happens when the PR is NOT against a fork. Its been >>>> difficult to debug since most of our developers >>>> use their own forks. >>>> >>> >>> I think that is the same condition I'm using with the git client plugin >>> multibranch configuration that I'm using. >>> >>> >>>> I think I'm behind on most of the Pipeline related plugins except for >>>> the branch-source plugin. I had attempted a big >>>> upgrade of plugins last week that ended badly. Going to retry this >>>> weekend. >>>> >>>> What is the "Jenkins multibranch folder" ? I don't think we're actively >>>> using the multibranch plugin. Its unclear to me if we need >>>> that plugin or not if we're already using the branch-source plugin. The >>>> branch-source plugin seems to do everything we need >>>> to do. I think we will eventually want to use the multibranch plugin to >>>> provide different behaviors between a dev, qa or master branch. >>>> Assuming I actually understand how that plugin works. >>>> >>>> >>> I should have been more clear. If you're using the GitHub branch source >>> plugin to define the job, then you're creating a multibranch job. The >>> multibranch job is represented as a folder which contains one job for each >>> branch in the repository. The containing folder is what I called the >>> "Jenkins multibranch folder". No other plugin is needed. >>> >>> Mark Waite >>> >>> Tom >>>> >>>> >>>> >>>> On Thu, Mar 28, 2019 at 5:11 PM Mark Waite wrote: >>>> >>>>> That's quite surprising, since my PR evaluation for the git client >>>>> plugin on my own fork is running with GitHub and is only showing the >>>>> 'pr-merge' job. >>>>> >>>>> Is the second job visible when executing in the Jenkins multibranch >>>>> folder? If so, then I'm puzzled, because you're seeing something that I'm >>>>> not seeing. >>>>> >>>>> Are you running the most recent versions of the various plugins? >>>>> >>>>> Mark Waite >>>>> >>>>> On Thu, Mar 28, 2019 at 6:06 PM Tom Duerr wrote: >>>>> >>>>>> Mark, >>>>>> I already have the "Exclude branches that are also filed as PRs" set. >>>>>> Guess that's part of my confusion. >>>>>> >>>>>> On Thu, Mar 28, 2019 at 4:58 PM Mark Waite wrote: >>>>>> >>>>>>> It might also work to filter branches based on the branch name at >>>>>>> some level, but that's more complicated that changing the "Discover >>>>>>> branches" setting in the plugin. >>>>>>> >>>>>>> Picture looks like this: >>>>>>> >>>>>>> [image: image.png] >>>>>>> >>>>>>> On Thu, Mar 28, 2019 at 5:22 PM Slide wrote: >>>>>>> >>>>>>>> This would generally be the branch filter parameter wouldn't it? >>>>>>>> You'd want to filter on the pr-* and master braches >>>>>>>> >>>>>>>> On Thu, Mar 28, 2019, 16:20 Mark Waite wrote: >>>>>>>> >>>>>>>>> I thought that was an indication that the GitHub branch source is >>>>>>>>> defined to both create a job for each branch and for each pull >>>>>>>>> request. I >>>>>>>>> think you need to reconfigure the job to not build a branch if it has >>>>>>>>> a >>>>>>>>> matching pull request. >>>>>>>>> >>>>>>>>> On Thu, Mar 28, 2019 at 5:17 PM Tom Duerr wrote: >>>>>>>>> >>>>>>>>>> Jenkin 2.138 >>>>>>>>>> Branch-Source plugin 2.4.2 >>>>>>>>>> SCM=Github Enterprise >>>>>>>>>> Amazon Linux >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> We've recently started converting from freestyle jobs to >>>>>>>>>> Jenkinsfile/pipelines. >>>>>>>>>> >>>>>>>>>> We're seeing odd behaviors when pull requests(PR) are created >>>>>>>>>> directly from our >>>>>>>>>> main repo and not from a fork of the repo. Specifically around >>>>>>>>>> the git status checks. PRs that are NOT created from a fork >>>>>>>>>> result in two >>>>>>>>>> git checks and 2 full builds being kicked off. >>>>>>>>>> We see these 2 checks: >>>>>>>>>> >>>>>>>>>> continuous-integration/jenkins/branch >>>>>>>>>> continuous-integration/jenkins/pr-merge >>>>>>>>>> >>>>>>>>>> The PRs from the developers fork, cause only 1 check and 1 build. >>>>>>>>>> continuous-integration/jenkins/pr-merge >>>>>>>>>> >>>>>>>>>> Does anyone know how the 2 checks get created? >>>>>>>>>> Whats the difference between >>>>>>>>>> continuous-integration/jenkins/branch and >>>>>>>>>> continuous-integration/jenkins/pr-merge? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tom >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> Thanks! >>>>>>>>> Mark Waite >>>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>> -- >>>>>>> Thanks! >>>>>>> Mark Waite >>>>>>> >>>>>>> >>>>>>> -- >>>>>> >>>>> >>>>> -- >>>>> Thanks! >>>>> Mark Waite >>>>> >>>>> -- >>>>> >>>> >>> -- >>> Thanks! >>> Mark Waite >>> >>> -- >>> 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+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtFysXx%3Dnmb-UsBicoPoyoTBz6Ff2%2BkUo3FRR1v3awCpVg%40mail.gmail.com >>> <https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtFysXx%3Dnmb-UsBicoPoyoTBz6Ff2%2BkUo3FRR1v3awCpVg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-users/04d47abd-75d0-48a4-a8ea-c4de77c1c84a%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-users/04d47abd-75d0-48a4-a8ea-c4de77c1c84a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Thanks! Mark Waite -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtEZcSnqJtPRXMWcckdkVr2zZkr-QQkucm3h8ta87hGrwQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
