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

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

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Fixed
    • git-plugin
    • None

    Attachments

      Issue Links

        Activity

          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.

          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.
          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.

          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.
          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.

          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.
          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
          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
          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.

          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

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

            Dates

              Created:
              Updated:
              Resolved: