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

Jenkins triggers builds on git SCM changes, but nothing changed

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

      Hi,

      Recently I've upgraded Jenkins to ver 1.508 and many plugins (including Jenkins GIT plugin from 1.1.25 to 1.3.0) and since that time I got a lot of my jobs using Git SCM running very frequently without any reason.
      None of my jobs using "Poll SCM" in "Build Triggers". But I see them running with build cause "Started by an SCM change" though very often there are no changes at all. And Polling Log is always empty.

        1. Image_1.png
          Image_1.png
          32 kB
        2. image-2018-10-17-14-03-19-028.png
          image-2018-10-17-14-03-19-028.png
          10 kB
        3. image-2018-10-17-14-04-05-260.png
          image-2018-10-17-14-04-05-260.png
          3 kB
        4. IntegritySCM.zip
          156 kB
        5. view1.JPG
          view1.JPG
          20 kB
        6. View2.JPG
          View2.JPG
          33 kB

          [JENKINS-17614] Jenkins triggers builds on git SCM changes, but nothing changed

          Mark Waite added a comment -

          dmaxfield I don't know of any other work arounds beyond those that I listed earlier.

          Mark Waite added a comment - dmaxfield I don't know of any other work arounds beyond those that I listed earlier.

          Anto Salnikov added a comment -

          Having the same issue. 

          Anto Salnikov added a comment - Having the same issue. 

          Same problem, any news??

          Vinicius Pazzini added a comment - Same problem, any news??

          Mark Waite added a comment -

          Mark Waite added a comment - pazzinivinicius no news

          Nina Jiang added a comment - - edited

          Recently I got into this issue and fix it by identify the right 'Branch Specifier '.

          Set the 'Branch Specifier ' as '*/dev' will cause the problem because I have a local branch called 'local/dev' and the auto-pull won't update the local branch.

          Set the 'Branch Specifier ' as 'origin/dev', the poll SCM get back to normal.

           

           

          Nina Jiang added a comment - - edited Recently I got into this issue and fix it by identify the right 'Branch Specifier '. Set the 'Branch Specifier ' as '*/dev' will cause the problem because I have a local branch called 'local/dev' and the auto-pull won't update the local branch. Set the 'Branch Specifier ' as 'origin/dev', the poll SCM get back to normal.    

          I had the same problem with some feature branches, but after setting 'Branch Specifier' with 'refs/heads/feature/...' and not only 'feature/...' everything works fine now.

          Samuel Zihlmann added a comment - I had the same problem with some feature branches, but after setting 'Branch Specifier' with 'refs/heads/feature/...' and not only 'feature/...' everything works fine now.

          Jishwin added a comment -

          I am also facing this same issue now. In my branch specifier it is " */develop ". Any ideas on how to resolve this?

          Jishwin added a comment - I am also facing this same issue now. In my branch specifier it is " */develop ". Any ideas on how to resolve this?

          Barrie added a comment -

          We had the same issue, removing one of the recent branches added and removing the workspace fixed it.

          Barrie added a comment - We had the same issue, removing one of the recent branches added and removing the workspace fixed it.

          rahul sharma added a comment - - edited

          I am also facing this issue in my branch one branch i.e develop using freestyle job poll scm automatically trigger with in a second without any new commit i resolve this issue by below steps:

          1 . Clean workspace of particular pipeline from  server where Jenkins is deploy location will be (/var/lib/jenkins/workspace/) under workspace folder you will get all pipeline so remove particular job which you having a issue.

          2 Perform above step if issue is resolve by performing above step thats great if not perform one more step after doing this first step in you pipeline configuration 

          Set the 'Branch Specifier ' as 'refs/heads/develop'

          rahul sharma added a comment - - edited I am also facing this issue in my branch one branch i.e develop using freestyle job poll scm automatically trigger with in a second without any new commit i resolve this issue by below steps: 1 . Clean workspace of particular pipeline from  server where Jenkins is deploy location will be (/var/lib/jenkins/workspace/) under workspace folder you will get all pipeline so remove particular job which you having a issue. 2 Perform above step if issue is resolve by performing above step thats great if not perform one more step after doing this first step in you pipeline configuration  Set the 'Branch Specifier ' as 'refs/heads/develop'

          Andrew Robinson added a comment - - edited

          I am seeing this issue in our builds. Our specifier is `refs/remotes/origin/dev`. I created a copy of the job that was "corrupted" and it worked for 1-2 weeks and then starting building on every commit in git (not just commits to our dev branch). 

          The git polling log shows an incorrect git hash after several correct git hashes. 

          In the below log, hash 1db609585eedb7d551abe735b69b8aa08bf57b2e is a commit on May 24 and hash 13b0645d2d0eef5a33f2cca02e26ff8161fe13fd is a commit from May 26. The polling log correctly shows it finding the May 26 commit several times and then, seemingly randomly, it finds the May 24 hash. 

          Example output from the git polling log in Jenkins:

           

           > git ls-remote -h – git@github.com:my-company-tools/our-code.git # timeout=10
          Found 438 remote heads on git@github.com:my-company-tools/our-code.git
          [poll] Latest remote head revision on refs/heads/dev is: 13b0645d2d0eef5a33f2cca02e26ff8161fe13fd
          Using strategy: Default
          [poll] Last Built Revision: Revision 13b0645d2d0eef5a33f2cca02e26ff8161fe13fd (refs/remotes/origin/dev)
          The recommended git tool is: git
          using credential theDeployKey
           > git --version # timeout=10
           > git --version # 'git version 2.17.1'
          using GIT_SSH to set credentials Deploy key for our-code mono-repository in GitHub
          Verifying host key using manually-configured host key entries
           > git ls-remote -h – git@github.com:my-company-tools/our-code.git/ # timeout=10
          Found 438 remote heads on git@github.com:my-company-tools/our-code.git/
          Using strategy: Default
          [poll] Last Built Revision: Revision 1db609585eedb7d551abe735b69b8aa08bf57b2e (refs/remotes/origin/dev)
          The recommended git tool is: git
          using credential theDeployKey
           > git --version # timeout=10
           > git --version # 'git version 2.17.1'
          using GIT_SSH to set credentials Deploy key for our-code mono-repository in GitHub
          Verifying host key using manually-configured host key entries
           > git ls-remote -h – git@github.com:my-company-tools/our-code.git # timeout=10
          Found 438 remote heads on git@github.com:my-company-tools/our-code.git
          [poll] Latest remote head revision on refs/heads/dev is: 13b0645d2d0eef5a33f2cca02e26ff8161fe13fd
          Done. Took 13 sec
          Changes found

          I found this in our groovy:
          script.checkout([
          $class: 'GitSCM',
          branches: [[name: "*/${gitBranch}"]],
          doGenerateSubmoduleConfigurations: false,
           
          I changed it to try:

          script.checkout([
          $class: 'GitSCM',
          branches: [[name: "refs/remotes/origin/${gitBranch}"]],
          doGenerateSubmoduleConfigurations: false,

           

          We are still seeing the issue. I'm going to have someone in IT try deleting the workspace folder to see if that helps. Any other suggestions?

          Andrew Robinson added a comment - - edited I am seeing this issue in our builds. Our specifier is `refs/remotes/origin/dev`. I created a copy of the job that was "corrupted" and it worked for 1-2 weeks and then starting building on every commit in git (not just commits to our dev branch).  The git polling log shows an incorrect git hash after several correct git hashes.  In the below log, hash 1db609585eedb7d551abe735b69b8aa08bf57b2e is a commit on May 24 and hash 13b0645d2d0eef5a33f2cca02e26ff8161fe13fd is a commit from May 26. The polling log correctly shows it finding the May 26 commit several times and then, seemingly randomly, it finds the May 24 hash.  Example output from the git polling log in Jenkins:    > git ls-remote -h – git@github.com:my-company-tools/our-code.git # timeout=10 Found 438 remote heads on git@github.com:my-company-tools/our-code.git [poll] Latest remote head revision on refs/heads/dev is: 13b0645d2d0eef5a33f2cca02e26ff8161fe13fd Using strategy: Default [poll] Last Built Revision: Revision 13b0645d2d0eef5a33f2cca02e26ff8161fe13fd (refs/remotes/origin/dev) The recommended git tool is: git using credential theDeployKey  > git --version # timeout=10  > git --version # 'git version 2.17.1' using GIT_SSH to set credentials Deploy key for our-code mono-repository in GitHub Verifying host key using manually-configured host key entries  > git ls-remote -h – git@github.com:my-company-tools/our-code.git/ # timeout=10 Found 438 remote heads on git@github.com:my-company-tools/our-code.git/ Using strategy: Default [poll] Last Built Revision: Revision 1db609585eedb7d551abe735b69b8aa08bf57b2e (refs/remotes/origin/dev) The recommended git tool is: git using credential theDeployKey  > git --version # timeout=10  > git --version # 'git version 2.17.1' using GIT_SSH to set credentials Deploy key for our-code mono-repository in GitHub Verifying host key using manually-configured host key entries  > git ls-remote -h – git@github.com:my-company-tools/our-code.git # timeout=10 Found 438 remote heads on git@github.com:my-company-tools/our-code.git [poll] Latest remote head revision on refs/heads/dev is: 13b0645d2d0eef5a33f2cca02e26ff8161fe13fd Done. Took 13 sec Changes found I found this in our groovy: script.checkout([ $class: 'GitSCM', branches: [ [name: "*/${gitBranch}"] ], doGenerateSubmoduleConfigurations: false,   I changed it to try: script.checkout([ $class: 'GitSCM', branches: [ [name: "refs/remotes/origin/${gitBranch}"] ], doGenerateSubmoduleConfigurations: false,   We are still seeing the issue. I'm going to have someone in IT try deleting the workspace folder to see if that helps. Any other suggestions?

            rahul14u rahul sharma
            uvizhe Alexander Uvizhev
            Votes:
            56 Vote for this issue
            Watchers:
            72 Start watching this issue

              Created:
              Updated:
              Resolved: