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"

          L J added a comment -

          I had success working around this by deactivating all jobs and then slowly activating them. The error seemed to be caused by too many jobs making git requests at once. Scripts pasted below. The second one times out (proxy 502 error) but still runs to completion. Basic idea stolen from a Jenkins wiki page.

          import hudson.model.*

          // For each project
          for(item in Hudson.instance.items) {
          println("JOB : "+item.name)
          item.disabled=true
          item.save()
          println("\n=======\n")
          }
          -----------------------------------------------------

          import hudson.model.*

          // For each project
          for(item in Hudson.instance.items) {
          println("JOB : "+item.name)
          if (item.disabled == true)

          { item.disabled=false item.save() Object.sleep(25000) }

          }

          L J added a comment - I had success working around this by deactivating all jobs and then slowly activating them. The error seemed to be caused by too many jobs making git requests at once. Scripts pasted below. The second one times out (proxy 502 error) but still runs to completion. Basic idea stolen from a Jenkins wiki page. import hudson.model.* // For each project for(item in Hudson.instance.items) { println("JOB : "+item.name) item.disabled=true item.save() println("\n=======\n") } ----------------------------------------------------- import hudson.model.* // For each project for(item in Hudson.instance.items) { println("JOB : "+item.name) if (item.disabled == true) { item.disabled=false item.save() Object.sleep(25000) } }

          Daniel Haskin added a comment -

          We have the same problem, but the git executable is flock'ed on our server, so that only one process can actually run the git at one time. The issue still persists for us, however.

          Daniel Haskin added a comment - We have the same problem, but the git executable is flock'ed on our server, so that only one process can actually run the git at one time. The issue still persists for us, however.

          Justin Zaun added a comment -

          Hi everyone. I registered this issue in the "kickstarting" section on FreedomSponsors. This means that if you need this issue that bad, you can go to http://www.freedomsponsors.org/core/issue/113/jobs-trigger-continually-even-though-there-are-no-changes-due-to-git-repository-being-corrupt and offer a few bucks for it.

          Justin Zaun added a comment - Hi everyone. I registered this issue in the "kickstarting" section on FreedomSponsors. This means that if you need this issue that bad, you can go to http://www.freedomsponsors.org/core/issue/113/jobs-trigger-continually-even-though-there-are-no-changes-due-to-git-repository-being-corrupt and offer a few bucks for it.

          Justin Zaun added a comment -

          Is it at least possible to not trigger the build on this error and just wait till the next check?

          Justin Zaun added a comment - Is it at least possible to not trigger the build on this error and just wait till the next check?

          fixed by switching to JGit implementation in git-client plugin
          using git cli and parsing output is a fragile solution that I expect to fully replace with pure JGit

          Nicolas De Loof added a comment - fixed by switching to JGit implementation in git-client plugin using git cli and parsing output is a fragile solution that I expect to fully replace with pure JGit

          Sean Flanigan added a comment -

          It seems that JGit was later disabled by default in git-client-plugin 1.0.5 because of problems with JGit.

          Is there a solution for this continual trigger problem when using git cli?

          Sean Flanigan added a comment - It seems that JGit was later disabled by default in git-client-plugin 1.0.5 because of problems with JGit. Is there a solution for this continual trigger problem when using git cli?

          Reopening the issue as JGit has problems on its own

          Oliver Gondža added a comment - Reopening the issue as JGit has problems on its own

          Narayana katooru added a comment - - edited

          Noticed  this on my jenkins. Is this still open?

          Narayana katooru added a comment - - edited Noticed  this on my jenkins. Is this still open?

          It is funny that this issue still exists after 8 years.

          Murali Srinivasan added a comment - It is funny that this issue still exists after 8 years.

          Mark Waite added a comment -

          chandramuralis I'm happy to consider a pull request from someone with tests that show the problem, code changes to resolve the problem, and a detailed explanation of the root cause of the problem. I've not encountered this problem in my use of the git plugin.

          Mark Waite added a comment - chandramuralis I'm happy to consider a pull request from someone with tests that show the problem, code changes to resolve the problem, and a detailed explanation of the root cause of the problem. I've not encountered this problem in my use of the git plugin.

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

              Created:
              Updated: