• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • git-plugin
    • None
    • ubuntu
      Jenkins 1.619
      Git Plugin 2.4.0
      Git-client plugin 1.18.0
      Github plugin 1.21.1

      Enable: Execute concurrent builds if necessary
      Branch specifier *
      Enable: Build when a change is pushed to GitHub
      Enable: Prune stale remote-tracking branches

      I have 6 executors.
      Every branch will then be built one times on each workspace. That is 6 times in total for every commit

      Duplicate builds say:
      """
      No changes.
      Started by an SCM change (or Started by Github push by someone)
      """

          [JENKINS-30016] Git Duplicate build for every workspace

          X Chen added a comment -

          This does not happen all the time, but frequent enough to be annoying.
          Occasionally I notice that all executors are building the same branch/same sha.

          X Chen added a comment - This does not happen all the time, but frequent enough to be annoying. Occasionally I notice that all executors are building the same branch/same sha.

          Mark Waite added a comment - - edited

          Can you provide an example of the GitHub webhook that is being used to start the polling of your builds? In particular, is there a "branches" parameter or a "sha1" parameter?

          Also, does the same problem occur when "Execute concurrent builds" is disabled?

          Mark Waite added a comment - - edited Can you provide an example of the GitHub webhook that is being used to start the polling of your builds? In particular, is there a "branches" parameter or a "sha1" parameter? Also, does the same problem occur when "Execute concurrent builds" is disabled?

          Mark Waite added a comment - - edited

          I don't have access to a GitHub webhook, so I attempted to duplicate the problem from a simple webhook from a bare git repository. I think I may have seen the failure in about 1 in 20 builds. Here are the steps I tried:

          1. Configure a job with Git as SCM using git://mark-pc1.markwaite.net/git/mwaite/bin.git as the URL
          2. Enable concurrent execution of the job
          3. Set quiet period to 0
          4. Limit the job to execute on any of 12 different slaves (windows || linux)
          5. Enable SCM polling but do not set any polling value (so that notifyCommit is primary way to start job)
          6. Add an Xshell build step "git log -n 1"
          7. Poll now with the job to run the first build
          8. Commit a change to the bare repository, confirm the change is detected and job runs once and only once
          9. Create a fast commit loop which pushes a series of changes to the bare repository
            for a in 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
            do 
              date >> README.md && git add README.md && git commit -m "Add $(date) to README" && git push
            done
            

          I ran that tight loop multiple times then compared the SHA1 of many builds and their predecessor builds. In the 100+ builds that were run, about 1 in 20 showed the preceding job using the same SHA1 hash as the running job.

          Mark Waite added a comment - - edited I don't have access to a GitHub webhook, so I attempted to duplicate the problem from a simple webhook from a bare git repository. I think I may have seen the failure in about 1 in 20 builds. Here are the steps I tried: Configure a job with Git as SCM using git://mark-pc1.markwaite.net/git/mwaite/bin.git as the URL Enable concurrent execution of the job Set quiet period to 0 Limit the job to execute on any of 12 different slaves (windows || linux) Enable SCM polling but do not set any polling value (so that notifyCommit is primary way to start job) Add an Xshell build step "git log -n 1" Poll now with the job to run the first build Commit a change to the bare repository, confirm the change is detected and job runs once and only once Create a fast commit loop which pushes a series of changes to the bare repository for a in 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 do date >> README.md && git add README.md && git commit -m "Add $(date) to README" && git push done I ran that tight loop multiple times then compared the SHA1 of many builds and their predecessor builds. In the 100+ builds that were run, about 1 in 20 showed the preceding job using the same SHA1 hash as the running job.

          X Chen added a comment -

          I actually dont know how to view "an example of the GitHub webhook", Could you advice what is that referred to?

          I just set quite period to 10s, And I have not observed such issue again. I will keep watching and let you know my observation.

          X Chen added a comment - I actually dont know how to view "an example of the GitHub webhook", Could you advice what is that referred to? I just set quite period to 10s, And I have not observed such issue again. I will keep watching and let you know my observation.

          Mark Waite added a comment -

          cxmcc, the request for the example of the GitHub webhook was an attempt to see how the problem might be duplicated without requiring that I install and configure a GitHub webhook into my environment.

          Mark Waite added a comment - cxmcc , the request for the example of the GitHub webhook was an attempt to see how the problem might be duplicated without requiring that I install and configure a GitHub webhook into my environment.

          X Chen added a comment -

          I have not observed same issue again after setting quiet period.
          Before that this case happens way more than 1 in 20 times. More like 1 in 3 times.

          Some info may help reproducing the issue:
          1. Building the project takes ~2-3min
          2. Sometimes git commits are big, it may take up to 10s to checkout changes.
          3. Duplicate build only happens at most once for each sha in each workspace.

          X Chen added a comment - I have not observed same issue again after setting quiet period. Before that this case happens way more than 1 in 20 times. More like 1 in 3 times. Some info may help reproducing the issue: 1. Building the project takes ~2-3min 2. Sometimes git commits are big, it may take up to 10s to checkout changes. 3. Duplicate build only happens at most once for each sha in each workspace.

          Mark Waite added a comment -

          Thanks for the additional hint. Since you've found an acceptable workaround for you, and I have many other areas of the plugin that need my attention, I won't spend further effort on this bug.

          Mark Waite added a comment - Thanks for the additional hint. Since you've found an acceptable workaround for you, and I have many other areas of the plugin that need my attention, I won't spend further effort on this bug.

            Unassigned Unassigned
            cxmcc X Chen
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: