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

git polling mechanism can have build in infinite loop

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: git-plugin
    • Labels:
      None
    • Similar Issues:

      Description

      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.

        Attachments

          Activity

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

          Show
          krosenvold 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.
          Hide
          scm_issue_link 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

          Show
          scm_issue_link 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
          Hide
          ndeloof 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

          Show
          ndeloof 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
          Hide
          krosenvold 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.

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

            People

            • Assignee:
              ndeloof Nicolas De Loof
              Reporter:
              krosenvold Kristia Rosenvold
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated: