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

Git plugin 2.0: Git polling causes builds even if no changes

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Critical
    • Resolution: Fixed
    • Component/s: git-plugin
    • Labels:
      None
    • Similar Issues:

      Attachments

        Issue Links

          Activity

          Hide
          phil_seremin Phil Seremin added a comment - - edited

          I have done the same, but Jenkins did two builds again: one with changes, and the one following that without any changes. I must be missing something.

          Show
          phil_seremin Phil Seremin added a comment - - edited I have done the same, but Jenkins did two builds again: one with changes, and the one following that without any changes. I must be missing something.
          Hide
          markewaite Mark Waite added a comment -

          That probably indicates that there is some other, additional bug (or condition) which is causing two builds. If you e-mail me your config.xml file for the job, or upload it to this bug report, I can compare your job configuration and my job configuration to see if I can identify any obvious reasons why the plugin would see your job as needing to schedule a second build.

          The typical reason why a second build is immediately scheduled is that the plugin thinks the "Branches to build" matches two different branches, and both branches have changes. If polling detects multiple branches to build, it will immediately schedule them both.

          You could also add the "Force polling using workspace" behaviour to see if that changes the behavior.

          Show
          markewaite Mark Waite added a comment - That probably indicates that there is some other, additional bug (or condition) which is causing two builds. If you e-mail me your config.xml file for the job, or upload it to this bug report, I can compare your job configuration and my job configuration to see if I can identify any obvious reasons why the plugin would see your job as needing to schedule a second build. The typical reason why a second build is immediately scheduled is that the plugin thinks the "Branches to build" matches two different branches, and both branches have changes. If polling detects multiple branches to build, it will immediately schedule them both. You could also add the "Force polling using workspace" behaviour to see if that changes the behavior.
          Hide
          phil_seremin Phil Seremin added a comment -

          I've attached a file.

          Git Build Data page shows identical information for both normal and duplicate builds.

          Show
          phil_seremin Phil Seremin added a comment - I've attached a file. Git Build Data page shows identical information for both normal and duplicate builds.
          Hide
          markewaite Mark Waite added a comment -

          I don't see many differences between your config.xml and the version I used to test the behaviour.

          Some of the differences I see (which may be worth you investigating):

          1. I enabled "prune stale branches" as an additional behaviour (since I don't like have stale branches lurking in my Jenkins workspaces). If you have stale branches in the Jenkins workspace, that might (conceivably) cause a duplicate build
          2. I don't have a Pre-SCM build step. I don't know what's inside the script you use for your Pre-SCM build step, but that might cause enough of a repository change to result in an additional build
          Show
          markewaite Mark Waite added a comment - I don't see many differences between your config.xml and the version I used to test the behaviour. Some of the differences I see (which may be worth you investigating): I enabled "prune stale branches" as an additional behaviour (since I don't like have stale branches lurking in my Jenkins workspaces). If you have stale branches in the Jenkins workspace, that might (conceivably) cause a duplicate build I don't have a Pre-SCM build step. I don't know what's inside the script you use for your Pre-SCM build step, but that might cause enough of a repository change to result in an additional build
          Hide
          phil_seremin Phil Seremin added a comment -

          Bingo. Thanks for your comments, and sorry for wasting your time. My pre-build step script includes a version update if code changes are detected. It then commits and pushes the new version to the main Git repo. Therefore before the first build is finished Jenkins is already notified about a new commit (by itself) which it reacts to by starting a second build. At least that's how I understand it now.

          I have set the job to ignore commits by jenkins user, and will see if the Branch Specifier set to "refs/remotes/origin/master" helps the double build issue.

          Show
          phil_seremin Phil Seremin added a comment - Bingo. Thanks for your comments, and sorry for wasting your time. My pre-build step script includes a version update if code changes are detected. It then commits and pushes the new version to the main Git repo. Therefore before the first build is finished Jenkins is already notified about a new commit (by itself) which it reacts to by starting a second build. At least that's how I understand it now. I have set the job to ignore commits by jenkins user, and will see if the Branch Specifier set to "refs/remotes/origin/master" helps the double build issue.

            People

            • Assignee:
              ndeloof Nicolas De Loof
              Reporter:
              rprots Roman Prots'
            • Votes:
              15 Vote for this issue
              Watchers:
              30 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: