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

git polling mechanism can have build in infinite loop

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

      We have a problem on the ASF git integration that causes change detection logic to always trigger changes, subsequently running the builds non-stop.

      I am quiet sure I have tracked this and will explain it here:

      jenkins-core:

      https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L1404

      Look at the catch-block surrounding the call to "poll".

      https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitSCM.java#L678
      https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitSCM.java#L741

      Both of these method calls can produce a "GitException" which is of type RunTimeException. When they hit the "catch" in AbstractProject#poll, they will enter the RuntimeException block.

      The root cause seems to be that GitAPI status code detection (GitAPI java line 824) does not distinguish between "IOException" and other kinds of exception. Given that we are unable to distinguish, it probably makes more sense to make the "poll" method wrap any git exception in an IOException, but the optimal would be to determine what status codes git uses for network related failures and throw ioexceptions in those cases.

          [JENKINS-15803] git polling mechanism can have build in infinite loop

          Kristia Rosenvold added a comment - - edited

          https://github.com/jenkinsci/git-plugin/pull/110 wraps any GitException in an IOException. Given that it is "impossible" to reliably separate real IOExceptions from configuration/corruption exceptions, this seems like the least evil of the two possible solutions. It should avoid runaway builds and the subsequent email spamming from jenkins.

          Kristia Rosenvold added a comment - - edited https://github.com/jenkinsci/git-plugin/pull/110 wraps any GitException in an IOException. Given that it is "impossible" to reliably separate real IOExceptions from configuration/corruption exceptions, this seems like the least evil of the two possible solutions. It should avoid runaway builds and the subsequent email spamming from jenkins.

          Code changed in jenkins
          User: Olivier Lamy
          Path:
          src/main/java/hudson/plugins/git/GitSCM.java
          http://jenkins-ci.org/commit/git-plugin/af5822b71b8a79f712c0bafeca09b96c5a15e2fb
          Log:
          Merge pull request #110 from krosenvold/master

          fix for JENKINS-15803

          Compare: https://github.com/jenkinsci/git-plugin/compare/58516aeebe9d...af5822b71b8a

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Olivier Lamy Path: src/main/java/hudson/plugins/git/GitSCM.java http://jenkins-ci.org/commit/git-plugin/af5822b71b8a79f712c0bafeca09b96c5a15e2fb Log: Merge pull request #110 from krosenvold/master fix for JENKINS-15803 Compare: https://github.com/jenkinsci/git-plugin/compare/58516aeebe9d...af5822b71b8a

          not sure to understand when this exception is thrown (your links don't match method calls in current code).
          also can't see relation with GitAPI#824 tag() method

          Nicolas De Loof added a comment - not sure to understand when this exception is thrown (your links don't match method calls in current code). also can't see relation with GitAPI#824 tag() method

          Kristia Rosenvold added a comment - - edited

          Temporarily change base class of GitException to a checked exception and it all becomes clear. Sorry about the line numbers, I was a few versions behind when I made the patch/issue

          git.getHeadRev
          buildChooser.getCandidateRevisions

          Both throw GitException in compareRemoteRevisionWithImpl

          The launchCommandIn GitAPI method throws GitException and is not able to distinguish why git fails (see http://stackoverflow.com/questions/4917871/does-git-return-specific-return-error-codes), unless one resorts to
          wicked screen scraping stuff.

          Kristia Rosenvold added a comment - - edited Temporarily change base class of GitException to a checked exception and it all becomes clear. Sorry about the line numbers, I was a few versions behind when I made the patch/issue git.getHeadRev buildChooser.getCandidateRevisions Both throw GitException in compareRemoteRevisionWithImpl The launchCommandIn GitAPI method throws GitException and is not able to distinguish why git fails (see http://stackoverflow.com/questions/4917871/does-git-return-specific-return-error-codes ), unless one resorts to wicked screen scraping stuff.

            Unassigned Unassigned
            krosenvold Kristia Rosenvold
            Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: