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

Errors fetching from remote repos don't fail the build

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: git-plugin
    • Labels:
      None
    • Environment:
      Ubunbu Karmic
    • Similar Issues:

      Description

      If there is a problem fetching new changes from a remote repo, this doesn't fail the build. Example:

      ERROR: Permission to simplegeo/python-geojson denied to geebus.
      fatal: The remote end hung up unexpectedly
      ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway
      

      Despite this, the build proceeds and is considered successful. This is extremely misleading, as it contains no new changes from the only repository it is configured to pull from. While I believe this behavior is nonsensical in the majority of cases, I think that one of two things should be changed:

      1. If every remote repo fails to update, fail.
      OR
      2. Add an option to fail if any remote repo fails to update.

        Attachments

          Issue Links

            Activity

            Hide
            abayer Andrew Bayer added a comment -

            I like option #1 - I'm not a particular fan of this behavior either, but I don't want to break anyone depending on the build continuing if one of multiple repos fails, and I don't want to add more configuration options than absolutely necessary.

            Show
            abayer Andrew Bayer added a comment - I like option #1 - I'm not a particular fan of this behavior either, but I don't want to break anyone depending on the build continuing if one of multiple repos fails, and I don't want to add more configuration options than absolutely necessary.
            Hide
            abayer Andrew Bayer added a comment -

            Fixed in latest at github.com/hudson/Hudson-GIT-plugin's master branch - if all fetches fail, the build will be marked as failed.

            Show
            abayer Andrew Bayer added a comment - Fixed in latest at github.com/hudson/Hudson-GIT-plugin's master branch - if all fetches fail, the build will be marked as failed.
            Hide
            jlongman jlongman added a comment -

            again

            Why would a build succeed if ANY of the source repositories fail? Is there any scenario where this makes sense? Have people said they would be happy if the build continued silently with out-of-date code?

            (Who are these people? I want to make sure I never submit a job application to them... )

            Show
            jlongman jlongman added a comment - again Why would a build succeed if ANY of the source repositories fail? Is there any scenario where this makes sense? Have people said they would be happy if the build continued silently with out-of-date code? (Who are these people? I want to make sure I never submit a job application to them... )
            Hide
            abayer Andrew Bayer added a comment -

            I can see situations where you're pulling from multiple repos, and if one of those repos should happen to be inaccessible or go away, that shouldn't stop the build from proceeding. But I definitely agree that there's a problem if no repo can succeed. And given that most configurations are going to just have the one repo anyway...

            Show
            abayer Andrew Bayer added a comment - I can see situations where you're pulling from multiple repos, and if one of those repos should happen to be inaccessible or go away, that shouldn't stop the build from proceeding. But I definitely agree that there's a problem if no repo can succeed. And given that most configurations are going to just have the one repo anyway...
            Hide
            eguess74 eguess74 added a comment -

            Hudson 1.379, git plugin v 1.1, only one repository configured to fetch from. The repository got renamed on the remote side. Fetch has failed during the poll. But it still says "continuing anyway"

            The problem is not fixed

            Show
            eguess74 eguess74 added a comment - Hudson 1.379, git plugin v 1.1, only one repository configured to fetch from. The repository got renamed on the remote side. Fetch has failed during the poll. But it still says "continuing anyway" The problem is not fixed
            Hide
            jlongman jlongman added a comment -

            @abayer - I finally understand what you mean by your reply - seriously I had no idea why anyone would want what you suggested. Multiple repositories should be renamed to indicate redundant or backup repositories as it doesn't imply a collection of repositories, rather backups, which is what I (and the creator of CORE-8082) inferred. "Multiple" tends to imply a collection - all mandatory - rather than a redundancy in my mind. Also, what happens if a repo fails partway through (does it clean the workspace before moving onto the next repo?)

            Show
            jlongman jlongman added a comment - @abayer - I finally understand what you mean by your reply - seriously I had no idea why anyone would want what you suggested. Multiple repositories should be renamed to indicate redundant or backup repositories as it doesn't imply a collection of repositories, rather backups, which is what I (and the creator of CORE-8082) inferred. "Multiple" tends to imply a collection - all mandatory - rather than a redundancy in my mind. Also, what happens if a repo fails partway through (does it clean the workspace before moving onto the next repo?)
            Hide
            garen Garen Parham added a comment -

            A common use case for the issue as described is for a build that has a sub-component that lives in another version control system.

            Think of any large open source project, which depends on many smaller libraries;

            For example, say you want to pull from super-duper-common-lib (e.g., zlib) via github, and without that one critical foreign lib the entire build will not work.

            Show
            garen Garen Parham added a comment - A common use case for the issue as described is for a build that has a sub-component that lives in another version control system. Think of any large open source project, which depends on many smaller libraries; For example, say you want to pull from super-duper-common-lib (e.g., zlib) via github, and without that one critical foreign lib the entire build will not work.

              People

              • Assignee:
                abayer Andrew Bayer
                Reporter:
                ieure ieure
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: