Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-18212

Branches get triggered for polling when we don't want them to

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Critical Critical
    • git-plugin
    • None
    • Jenkins Server: 1.5.10
      Git plugin: 1.3.0

      So what I am hoping to do is to prevent polling from happening on any branch besides the one that was changed. I thought by having the "branches=branch2" for example would trigger the plugin to only schedule a polling of that branch. The reason for this functionality is that we need certain users to be able to commit without triggering a build such as admin work/upper level scripts which don't impact our product. Even if I abort a build the next time someone pushes, the force polling will build that branch even though the push wasn't for that specific branch.

      Below you can see the output of what command we push, I would expect branch2 to kick off a poll but no other branch to do that.

      remote: branch=branch2, user=peter_kline, repo=flt/root

      remote: Running command: curl http://jenkins:8080/git/notifyCommit?url=git@gitserver:flt/root.git&branches=branch2

      remote: Scheduled polling of branch1
      remote: Scheduled polling of branch2
      remote: Scheduled polling of branch3
      remote: Scheduled polling of branch4
      remote: Scheduled polling of branch5
      remote: Scheduled polling of branch6
      remote: Scheduled polling of branch7
      remote: Scheduled polling of branch8
      remote: Scheduled polling of branch9
      remote: Scheduled polling of branch10
      remote: Scheduled polling of branch11
      remote: Scheduled polling of branch12
      remote: Scheduled polling of branch13
      remote: Scheduled polling of branch14
      To git@gitserver:flt/root.git
      9607b14..1daed8c branch2 -> branch2

          [JENKINS-18212] Branches get triggered for polling when we don't want them to

          Mark Waite added a comment - - edited

          Couldn't you avoid the problem with the "Polling ignores commits from certain users" functionality in the Git plugin to allow those admin work/upper level scripts to submit changes which don't impact the product? That will not prevent the polling, but it will prevent a build from being run as a result of the poll.

          Mark Waite added a comment - - edited Couldn't you avoid the problem with the "Polling ignores commits from certain users" functionality in the Git plugin to allow those admin work/upper level scripts to submit changes which don't impact the product? That will not prevent the polling, but it will prevent a build from being run as a result of the poll.

          Peter Kline added a comment -

          I don't see how that will help. When any push comes from any other job it will start a poll on all jobs that are set to poll. This in turn will cause the branch to see if there are any changes and start the build. Also, the use case may be that someone (not an admin) pushes and we don't want their build to start because we are queuing something so we kill the build immediately, again, as soon as any other branch pushes, the build gets kicked off.

          Peter Kline added a comment - I don't see how that will help. When any push comes from any other job it will start a poll on all jobs that are set to poll. This in turn will cause the branch to see if there are any changes and start the build. Also, the use case may be that someone (not an admin) pushes and we don't want their build to start because we are queuing something so we kill the build immediately, again, as soon as any other branch pushes, the build gets kicked off.

          Mark Waite added a comment -

          I think you may have misunderstood the result of "Polling ignores commits from certain users".

          I've copied your text and inserted what I believe actually happens in bold.

          When any push comes from any other job it will start a poll on all jobs that are set to poll. This in turn will cause the branch to see if there are any changes but will not start the build because the commit was from a user whose commits are ignored.

          I am assuming you don't mind if the polling happens, but rather that you do not want the build to happen due to a push from that admin work/upper level script commit.

          I don't understand your second use case description. If someone pushes and you don't want their build to start that time, but you do want it to start other times, then I don't see a way to use polling to monitor that repository. Polling assumes that a change on a monitored branch is expected to perform the build. Excluded users, excluded regions, and included regions have been used in the past to prevent builds, but the case you're describing with your second use case doesn't match with any of those exclusion techniques as far as I can tell.

          Mark Waite added a comment - I think you may have misunderstood the result of "Polling ignores commits from certain users". I've copied your text and inserted what I believe actually happens in bold . When any push comes from any other job it will start a poll on all jobs that are set to poll. This in turn will cause the branch to see if there are any changes but will not start the build because the commit was from a user whose commits are ignored . I am assuming you don't mind if the polling happens, but rather that you do not want the build to happen due to a push from that admin work/upper level script commit. I don't understand your second use case description. If someone pushes and you don't want their build to start that time, but you do want it to start other times, then I don't see a way to use polling to monitor that repository. Polling assumes that a change on a monitored branch is expected to perform the build. Excluded users, excluded regions, and included regions have been used in the past to prevent builds, but the case you're describing with your second use case doesn't match with any of those exclusion techniques as far as I can tell.

          Peter Kline added a comment -

          I guess my second scenario is more of what I am looking for, sorry for making it unclear. I want the ability to cancel a currently running build on branch2. I don't want a new build to start until a new push on branch2 regardless if they are an admin or not. What happens is when someone pushes on branch1, it will tell branch2 (and all other branches defined to poll) to start a poll. I was hoping that the &branches=branch2 in the curl command would tell the git plugin to only cause Jenkins to poll that branch.

          Peter Kline added a comment - I guess my second scenario is more of what I am looking for, sorry for making it unclear. I want the ability to cancel a currently running build on branch2. I don't want a new build to start until a new push on branch2 regardless if they are an admin or not. What happens is when someone pushes on branch1, it will tell branch2 (and all other branches defined to poll) to start a poll. I was hoping that the &branches=branch2 in the curl command would tell the git plugin to only cause Jenkins to poll that branch.

          Mark Waite added a comment -

          Thanks for the clarification.

          I believe the Git plugin intentionally polls all branches because it has a use case where users push branches to a central repository as "proposed changes", then Jenkins merges the content of those branches to an integration branch and pushes the resulting merge to the central repository. It has been referred to as "pre-tested commit" or "pre-tested merge".

          I like that use case very much, since it allows me to submit a change to the central repository for Jenkins evaluation, and only if Jenkins evaluates it successfully will the change be merged to the destination branch.

          Mark Waite added a comment - Thanks for the clarification. I believe the Git plugin intentionally polls all branches because it has a use case where users push branches to a central repository as "proposed changes", then Jenkins merges the content of those branches to an integration branch and pushes the resulting merge to the central repository. It has been referred to as "pre-tested commit" or "pre-tested merge". I like that use case very much, since it allows me to submit a change to the central repository for Jenkins evaluation, and only if Jenkins evaluates it successfully will the change be merged to the destination branch.

          Mark Waite added a comment -

          Would you be willing to consider this a request for an enhancement, rather than a bug?

          I think the plugin is behaving as intended by the original author and by the current maintainer, and implementing what you want will require some new coding, and may require some new concepts in the plugin.

          Mark Waite added a comment - Would you be willing to consider this a request for an enhancement, rather than a bug? I think the plugin is behaving as intended by the original author and by the current maintainer, and implementing what you want will require some new coding, and may require some new concepts in the plugin.

          Peter Kline added a comment -

          Yes a new enhancement is fine. I thought it was more of a bug since I believed mistakenly that the branch option was intended to do what I wanted (documentation was weak in its function).

          Peter Kline added a comment - Yes a new enhancement is fine. I thought it was more of a bug since I believed mistakenly that the branch option was intended to do what I wanted (documentation was weak in its function).

            Unassigned Unassigned
            peter_kline Peter Kline
            Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: