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

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

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • git-plugin
    • None

        [JENKINS-20767] Git plugin 2.0: Git polling causes builds even if no changes

        Phil Seremin added a comment -

        Is there any estimate when the official plugin release will be updated with a fix?

        Phil Seremin added a comment - Is there any estimate when the official plugin release will be updated with a fix?

        Mark Waite added a comment -

        The git-client-plugin 1.10.0 includes a change from alexanderlink which allows "refs/heads" and "refs/tags" as a prefix to declare a branch spec in "Branches to build" which is unambiguous.

        For example, if the branch to build should be the branch "develop/proposal" and the remote is named "origin", then the "Branches to build" value should be "refs/heads/develop/proposal".

        Refer to Alexander's detailed documentation for more information and for descriptions of the cases which still have issues.

        Mark Waite added a comment - The git-client-plugin 1.10.0 includes a change from alexanderlink which allows "refs/heads" and "refs/tags" as a prefix to declare a branch spec in "Branches to build" which is unambiguous. For example, if the branch to build should be the branch "develop/proposal" and the remote is named "origin", then the "Branches to build" value should be "refs/heads/develop/proposal". Refer to Alexander's detailed documentation for more information and for descriptions of the cases which still have issues.

        Mark Waite added a comment -

        Believed to be resolved with git-client-plugin 1.10.0 through the changes from alexanderlink

        Mark Waite added a comment - Believed to be resolved with git-client-plugin 1.10.0 through the changes from alexanderlink

        Phil Seremin added a comment - - edited

        I can't say I understood half of what the doc said, sorry. Would it be possible for you to explain how I need to configure my job? Currently my "Branches to build" says "master" and all works fine. I tried prepending it with "refs/heads/" and the build failed (ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.).

        I use Jenkins 1.570, git-client-plugin 1.10.0.

        Phil Seremin added a comment - - edited I can't say I understood half of what the doc said, sorry. Would it be possible for you to explain how I need to configure my job? Currently my "Branches to build" says "master" and all works fine. I tried prepending it with "refs/heads/" and the build failed (ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.). I use Jenkins 1.570, git-client-plugin 1.10.0.

        Mark Waite added a comment -

        I constructed a test job and set "Branches to build" to refs/remotes/origin/master. I believe that is an unambiguous declaration of the branch I usually would call "origin/master".

        Mark Waite added a comment - I constructed a test job and set "Branches to build" to refs/remotes/origin/master. I believe that is an unambiguous declaration of the branch I usually would call "origin/master".

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

        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.

        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 added a comment -

        I've attached a file.

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

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

        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

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

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

            Created:
            Updated:
            Resolved: