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 [email protected]. >>> 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 [email protected]. > 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 [email protected]. 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.
