Answers: <p>You could:  </p>
  
  <ul>
  <li>prune your branches. (guessing you'd have done this by now if feasible.)</li>
  <li>implement Jenkinsfile, a code-driven pipeline,
  and simply remove the jenkinsfile from the branches you don't want
  built or triggered by SCM-polling.</li>
  </ul>
  
Answers: CC BY-SA 3.0
Answers: 2017-10-28T02:25:20.753Z
Answers: 2017-10-28T02:25:20.753Z
Answers: esoterydactyl
Answers: <p>So... I had this issue and solved it by making sure I passed the pull request ID to the Jenkins job and the Branch ID from Pull Request. I've attached a screen shot. <a href="https://i.sstatic.net/0KR1m.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/0KR1m.png" alt="enter image description here"></a></p>
  
  <p>And this as well:</p>
  
  <p><a href="https://i.sstatic.net/1RUrV.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/1RUrV.png" alt="enter image description here"></a></p>
  
  <p>you can <em>absolutely</em> control what Jenkins pulls from your SCM w/the proper configurations - these should get you there. </p>
  
  <p>Also: I have polling disabled - you really don't want to use polling as it is expensive - configure a BitBucket PullRequest plugin to call your Jenkins job upon creation as you are doing and you shouldn't <em>need</em> to poll, although I don't know that particular plugin... this one is great:  </p>
  
  <p><a href="https://github.com/tomasbjerre/pull-request-notifier-for-bitbucket" rel="nofollow noreferrer">https://github.com/tomasbjerre/pull-request-notifier-for-bitbucket</a></p>
  
Answers: CC BY-SA 3.0
Answers: 2017-12-28T15:27:39.710Z
Answers: 2017-12-28T17:55:12.163Z
Answers: 2017-12-28T17:55:12.163Z
Answers: randomNerdboy
Answers: <p>One could use <a href="https://wiki.jenkins.io/display/JENKINS/PollSCM+Plugin" rel="nofollow noreferrer">SCM polling</a> and specify different branches that need to be polled.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-10-23T13:12:49.037Z
Answers: As I stated in my question, while this is a valid approach on a smaller scale, this is impractical for my case, where black/whitelisting branches would be a monumental task.
Answers: Alex
Answers: CC BY-SA 3.0
Answers: 2017-10-20T21:10:54.640Z
Answers: 2017-10-20T21:10:54.640Z
Answers: 030
Answers: <p>I believe it is now possible to configure the webhook on per-repo basis:</p>
  
  <p><a href="https://mohamicorp.atlassian.net/wiki/spaces/DOC/pages/381419546/Configuring+Webhook+To+Jenkins+for+Bitbucket+Bitbucket+Branch+Source+Plugin" rel="noreferrer">https://mohamicorp.atlassian.net/wiki/spaces/DOC/pages/381419546/Configuring+Webhook+To+Jenkins+for+Bitbucket+Bitbucket+Branch+Source+Plugin</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2018-08-15T07:11:24.350Z
Answers: 2018-08-15T07:11:24.350Z
Answers: Nune Isabekyan
Body: <p>We use Jenkins and have the Bitbucket plugin installed. We've got multiple repos and use webhooks for lots of jobs coming from our <code>foo</code> repo. No problems there, the jobs go off without a hitch. Now however we want to start running a couple jobs via webhook from our <code>bar</code> repo.</p>
  <h3>The Problem</h3>
  <p>The default behavior here is that as soon as we attach a webhook to <code>bar</code>, commits to either repo will trigger any job with polling. I know we can hardcode in logic in each job to either only build when commits match a certain pattern, or ignore any commits matching a pattern.</p>
  <p>Given the number of jobs we have that currently use polling this would be insanely unideal to have to code in to make it backwards compatible, not to mention potentially doing this again if we start running unit tests on even more repos in the future.</p>
  <h3>The Ideal Solution</h3>
  <p>I'm hoping I might be missing some way to differentiate between commits made from <code>foo</code> vs <code>bar</code> on the Bitbucket side, rather than needing to change anything in each Jenkins job. Ideally, there's some way to change the webhook so each repo gets its own url. Does this, or some other blanket solution, exist? (I will accept &quot;no&quot; as an answer if that's the case).</p>
  
Tags: <jenkins><jenkins-plugins><bitbucket><bcbsn>
Title: Bitbucket Webhook plugin for Jenkins - differentiate between branches
UserDisplayName: Alex
ThreadText: # Bitbucket Webhook plugin for Jenkins - differentiate between branches
  
  (Asked by: username_0 on 2017-06-06)
  
  We use Jenkins and have the Bitbucket plugin installed. We've got multiple repos and use webhooks for lots of jobs coming from our `foo` repo. No problems there, the jobs go off without a hitch. Now however we want to start running a couple jobs via webhook from our `bar` repo.
  
  ### The Problem
  
  The default behavior here is that as soon as we attach a webhook to `bar`, commits to either repo will trigger any job with polling. I know we can hardcode in logic in each job to either only build when commits match a certain pattern, or ignore any commits matching a pattern.
  
  Given the number of jobs we have that currently use polling this would be insanely unideal to have to code in to make it backwards compatible, not to mention potentially doing this again if we start running unit tests on even more repos in the future.
  
  ### The Ideal Solution
  
  I'm hoping I might be missing some way to differentiate between commits made from `foo` vs `bar` on the Bitbucket side, rather than needing to change anything in each Jenkins job. Ideally, there's some way to change the webhook so each repo gets its own url. Does this, or some other blanket solution, exist? (I will accept "no" as an answer if that's the case).
  
  **Tags:** jenkins, jenkins-plugins, bitbucket, bcbsn
  
  
  ---
  
  ## 4 answers
  
  ### Answer by username_4 on 2018-08-15. Score: 5 | Accepted answer
  
  I believe it is now possible to configure the webhook on per-repo basis:
  
  <https://mohamicorp.atlassian.net/wiki/spaces/DOC/pages/381419546/Configuring+Webhook+To+Jenkins+for+Bitbucket+Bitbucket+Branch+Source+Plugin>
  
  
  ---
  
  ### Answer by username_1 on 2017-10-28. Score: 2
  
  You could:
  
  * prune your branches. (guessing you'd have done this by now if feasible.)
  * implement Jenkinsfile, a code-driven pipeline,
    and simply remove the jenkinsfile from the branches you don't want
    built or triggered by SCM-polling.
  
  
  ---
  
  ### Answer by username_3 on 2017-10-20. Score: 1
  
  One could use [SCM polling](https://wiki.jenkins.io/display/JENKINS/PollSCM+Plugin) and specify different branches that need to be polled.
  
  > **Comments:**
  > **username_0**: As I stated in my question, while this is a valid approach on a smaller scale, this is impractical for my case, where black/whitelisting branches would be a monumental task.  
  
  ---
  
  ### Answer by username_2 on 2017-12-28. Score: 0
  
  So... I had this issue and solved it by making sure I passed the pull request ID to the Jenkins job and the Branch ID from Pull Request. I've attached a screen shot. [![enter image description here](https://i.sstatic.net/0KR1m.png)](https://i.sstatic.net/0KR1m.png)
  
  And this as well:
  
  [![enter image description here](https://i.sstatic.net/1RUrV.png)](https://i.sstatic.net/1RUrV.png)
  
  you can *absolutely* control what Jenkins pulls from your SCM w/the proper configurations - these should get you there.
  
  Also: I have polling disabled - you really don't want to use polling as it is expensive - configure a BitBucket PullRequest plugin to call your Jenkins job upon creation as you are doing and you shouldn't *need* to poll, although I don't know that particular plugin... this one is great:
  
  <https://github.com/tomasbjerre/pull-request-notifier-for-bitbucket>
  
  
  ---
  
  