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

Jobs trigger continually even though there are no changes due to git repository being "corrupt"

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • None

      There is a problem with the git polling mechanism which is causing all our jobs to kick themselves off continually. This happens at random times and just fixes itself, but is causing us all sorts of problems due to the large number of builds triggered.

      This is an example of the git polling log:

       
      Started on 28-Oct-2011 03:20:22
      Using strategy: Default
      [poll] Last Build : #480
      [poll] Last Built Revision: Revision abcb8a2492b390521e0c720f96f66a88eae09f18 (origin/master)
      Workspace has a .git repository, but it appears to be corrupt.
      No Git repository yet, an initial checkout is required
      Done. Took 0.26 sec
      Changes found
      

      This is caused when a "git rev-parse --verify HEAD" fails for some reason, but there is no logging to help in what might have gone wrong. It looks like the try/catch around the validateRevision line is too simplistic and the cause of the exception should be considered before returning false.

          [JENKINS-11547] Jobs trigger continually even though there are no changes due to git repository being "corrupt"

          James Cook created issue -

          I'm seeing the same issue in many of our repositories I configured in Jenkins. It would be great if this issue can be fixed.

          Murali Srinivasan added a comment - I'm seeing the same issue in many of our repositories I configured in Jenkins. It would be great if this issue can be fixed.

          marlene cote added a comment -

          We are also seeing builds getting kicked off when nothing has changed in the git repo. I hope you fix it soon.

          marlene cote added a comment - We are also seeing builds getting kicked off when nothing has changed in the git repo. I hope you fix it soon.

          Ulli Hafner added a comment -

          Here is an example of a 'continuously' building job: http://ci.jenkins-ci.org/view/Plugins/job/plugins_analysis-core/

          Ulli Hafner added a comment - Here is an example of a 'continuously' building job: http://ci.jenkins-ci.org/view/Plugins/job/plugins_analysis-core/

          Corey Groves added a comment -

          Seems to be Windows specific in our case. Our Linux build machines don't show this problem but all of our Windows build servers do.

          Corey Groves added a comment - Seems to be Windows specific in our case. Our Linux build machines don't show this problem but all of our Windows build servers do.

          Corey Groves added a comment -

          I would suggest this should be upgraded to blocking. The 20 or so jobs we have converted to Git are rendering the build server unusable since they are constantly firing.

          Corey Groves added a comment - I would suggest this should be upgraded to blocking. The 20 or so jobs we have converted to Git are rendering the build server unusable since they are constantly firing.

          This is really generating lot of unwanted build in my build server and unnecessarily triggering lot of emails.

          Murali Srinivasan added a comment - This is really generating lot of unwanted build in my build server and unnecessarily triggering lot of emails.
          Murali Srinivasan made changes -
          Priority Original: Critical [ 2 ] New: Blocker [ 1 ]

          nanda kishore added a comment -

          This problem didn't show up, if I make the builds to ping the scm in a definite order, and not at the same time. Meaning, first job pings scm at 1st min, second job 2nd min etc... So there wont be any congestion in the build pipeline. Previously all the jobs were pinging the scm at the same time and that could have resulted in the corrupt repos. I am not sure. I am just guessing. So now with an orderly pinging, the corrupt repos issue didn't show. THere aren't any unnecessary builds.

          nanda kishore added a comment - This problem didn't show up, if I make the builds to ping the scm in a definite order, and not at the same time. Meaning, first job pings scm at 1st min, second job 2nd min etc... So there wont be any congestion in the build pipeline. Previously all the jobs were pinging the scm at the same time and that could have resulted in the corrupt repos. I am not sure. I am just guessing. So now with an orderly pinging, the corrupt repos issue didn't show. THere aren't any unnecessary builds.

          @nanda Kishore, I tried your approach and still no luck.

          Murali Srinivasan added a comment - @nanda Kishore, I tried your approach and still no luck.

            Unassigned Unassigned
            james_cookie James Cook
            Votes:
            19 Vote for this issue
            Watchers:
            31 Start watching this issue

              Created:
              Updated: