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

Jobs get triggered twice from polling git scm

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • git-plugin
    • None

      We are seeing a weird problem occasionally on our jenkins setup ver 1.627
      git client 1.19
      git plugin 2.4 on ubuntu machine.
      I have a job configured to poll scm every 5 minutes
      sometimes, when there is a change the job gets triggered twice
      once with the relevant changes and the second time says "no changes"

          [JENKINS-30350] Jobs get triggered twice from polling git scm

          Christian added a comment - - edited

          Unfortunately the only thing that seems to work is either switching to hooks (which we can't do for reasons) or increase the time between polling. Of course, by increasing the time between polling, your builds will trigger less frequently. We have ours at about 1 hour, which means there could be a delay of up to 1 hour between the time someone commits and the time Jenkins picks it up. I really wish someone would fix this bug, but seeing as it has been around for over 3 years I don't think it will happen.

          Christian added a comment - - edited Unfortunately the only thing that seems to work is either switching to hooks (which we can't do for reasons) or increase the time between polling. Of course, by increasing the time between polling, your builds will trigger less frequently. We have ours at about 1 hour, which means there could be a delay of up to 1 hour between the time someone commits and the time Jenkins picks it up. I really wish someone would fix this bug, but seeing as it has been around for over 3 years I don't think it will happen.

          We were seeing the same problem happen consistently for our project, every time a change would be commited to git, two builds were being triggered with our job setup to poll for new changes every 2 minutes.

          But checking out our repository takes more than 4 minutes. So i assume the commit id is being stored right after the checkout has finished, which is why it was only 1 build that was always being queued up.

          I would recommend setting the poll schedule to a value that will definitely allow for a full repository checkout before polling again. In our case, 6 minutes seems to be doing the trick.

          Charles Clement added a comment - We were seeing the same problem happen consistently for our project, every time a change would be commited to git, two builds were being triggered with our job setup to poll for new changes every 2 minutes. But checking out our repository takes more than 4 minutes. So i assume the commit id is being stored right after the checkout has finished, which is why it was only 1 build that was always being queued up. I would recommend setting the poll schedule to a value that will definitely allow for a full repository checkout before polling again. In our case, 6 minutes seems to be doing the trick.

          cen We are also facing the same issue. Upon investigating this can reproducible, When you close the Source branch after the Merge request.

          Jenkins triggers multiple builds for the each push

          Maheshkumar Jeyaraj added a comment - cen We are also facing the same issue. Upon investigating this can reproducible, When you close the Source branch after the Merge request. Jenkins triggers multiple builds for the each push

          nikhil nanal added a comment -

          I am facing this issue as well with Multibranch pipelines on Jenkins 2.164 LTS and exactly as described by Christian above, my polling interval is 2 minutes and builds take longer. when there is pending build it gets retriggerred multiple ( arbitrary number) of times 

          nikhil nanal added a comment - I am facing this issue as well with Multibranch pipelines on Jenkins 2.164 LTS and exactly as described by Christian above, my polling interval is 2 minutes and builds take longer. when there is pending build it gets retriggerred multiple ( arbitrary number) of times 

          Mohamed Afsal added a comment -

          Hi Team, 

           

          Any update on this, I'm also facing the issue with Multibranch pipelines on Jenkins 2.22.1LTS.
          Dublicate Job shown as 

          Branch API version : 2.5.5
          Git plugin version : 4.2.2

          Mohamed Afsal added a comment - Hi Team,    Any update on this, I'm also facing the issue with Multibranch pipelines on Jenkins 2.22.1LTS. Dublicate Job shown as  Started by an SCM change  (22 times) Branch API version : 2.5.5 Git plugin version :  4.2.2

          Mark Waite added a comment -

          No update to offer afsal. Have you checked the alternatives offered in earlier comments in the issue?

          Mark Waite added a comment - No update to offer afsal . Have you checked the alternatives offered in earlier comments in the issue?

          Mohamed Afsal added a comment -

          markewaite Yes, tried but still issue persist

          Mohamed Afsal added a comment - markewaite Yes, tried but still issue persist

          Marwan added a comment -

          Hi, I encountered this problem and I found a workaround. we are using Github hooks and Jenkins.

          I wanted to trigger a Jenkins job for branches [let's say master, develop, and test]that I want to specify to trigger a job on push event. 

           

          for every push on one of those branches in the list, the job was triggered a couple of times.

          my workaround was to create a Jenkins job that triggers for every one of those branches alone

          in my Jenkins git "Branch Specifier (blank for 'any')"  I put only origin/master

          another job origin/develop and so on.

           

          what I noticed that sometimes it also trigger the same branches multiple times( after adding a filter in "polling ignores commits from certain users"

          the solution was to enable "Quiet period" in the advanced option under general and put the value of 10 seconds.

           

          TL'DR 

          1) create a job for each branch to trigger

          2) enable Quiet period in advanced option under general and put to a higher value than the default(5 is the default in my company)

           

           

          I did not check but maybe doing number 2 only can solve the problem.

           

           

          Marwan added a comment - Hi, I encountered this problem and I found a workaround. we are using Github hooks and Jenkins. I wanted to trigger a Jenkins job for branches [let's say master, develop, and test] that I want to specify to trigger a job on push event.    for every push on one of those branches in the list, the job was triggered a couple of times. my workaround was to create a Jenkins job that triggers for every one of those branches alone in my Jenkins git "Branch Specifier (blank for 'any')"  I put only origin/master another job origin/develop and so on.   what I noticed that sometimes it also trigger the same branches multiple times( after adding a filter in "polling ignores commits from certain users" the solution was to enable "Quiet period" in the advanced option under general and put the value of 10 seconds.   TL'DR  1) create a job for each branch to trigger 2) enable Quiet period in advanced option under general and put to a higher value than the default(5 is the default in my company)     I did not check but maybe doing number 2 only can solve the problem.    

          Vladislav Ponomarev added a comment - - edited

          It looks like the reason mentioned here in comment-364906 is exactly correct.

          Our (free style) build job has the build trigger configured as "GitHub hook trigger for GITScm polling".

          The moment we enabled "Automatically delete head branches" under our GitHub repo' settings, we started seeing the master branch builds triggered twice.

          I checked under GitHub webhook page - there are three virtually simultaneous events when the pull request is merged and the branch is automatically deleted:

          • for the master branch - "merge" event
          • for a pull request - "closed" event
          • for a head branch - "delete" event

          I presume the latter is the new one which causes an extra master build to be triggered - omitting the reason why it triggers a build for master and not for a  [deleted] head branch.

          For now we worked around it by stopping the build if the value of GIT_COMMIT and  GIT_PREVIOUS_COMMIT environment variables are different.

          Looking forward to see a proper fix though.

           

          Vladislav Ponomarev added a comment - - edited It looks like the reason mentioned here in  comment-364906  is exactly correct. Our (free style) build job has the build trigger configured as "GitHub hook trigger for GITScm polling". The moment we enabled "Automatically delete head branches" under our GitHub repo' settings, we started seeing the master branch builds triggered twice. I checked under GitHub webhook page - there are three virtually simultaneous events when the pull request is merged and the branch is automatically deleted: for the master branch - "merge" event for a pull request - "closed" event for a head branch - "delete" event I presume the latter is the new one which causes an extra master build to be triggered - omitting the reason why it triggers a build for master and not for a  [deleted] head branch. For now we worked around it by stopping the build if the value of GIT_COMMIT and  GIT_PREVIOUS_COMMIT environment variables are different. Looking forward to see a proper fix though.  

          Still seeing this issue in 2022. I can't believe it!

          Menasheh Peromsik added a comment - Still seeing this issue in 2022. I can't believe it!

            Unassigned Unassigned
            ohadbasan Ohad Basan
            Votes:
            29 Vote for this issue
            Watchers:
            37 Start watching this issue

              Created:
              Updated: