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

Git plugin should fail build when fetch fails

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Duplicate
    • git-plugin
    • None
    • hudson version 337 (slave.jar also)
      git version 1.6.3.2
      git plugin version 0.7.3

    Description

      The uid on our origin repository's user changed unexpectedly so that the user no longer owned his own home dir. When the slave tried to fetch from the repository using certificates (worked in the past) the certificate failed and git/ssh prompted for password. It failed (no tty, of course) and then the build continued without updating the code. It reported a success at the end. The build should have aborted immediately.

      Matrix build - master job
      Started by user gerhard
      Building remotely on hudson-206
      Checkout:3.0.2 / /usr/home/hudson/workspace/3.0.2 - hudson.remoting.Channel@10098b:hudson-206
      Last Build : #18
      Last Built Revision: Revision a2060dc86752c432eae0b81eb34ca18b0b5b858e (origin/3.0.1 )
      Checkout:3.0.2 / /usr/home/hudson/workspace/3.0.2 - hudson.remoting.LocalChannel@7a44e5
      Fetching changes from the remote Git repository
      Fetching upstream changes from ssh://hudson@gaia/git/Main.git
      [3.0.2] $ git fetch ssh://hudson@gaia/git/Main.git +refs/heads/*:refs/remotes/origin/*
      Permission denied, please try again.
      Permission denied, please try again.
      Permission denied (publickey,password).
      fatal: The remote end hung up unexpectedly
      ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway
      Seen branch in repository origin/3.0
      Seen branch in repository origin/next.major
      Seen branch in repository origin/next.minor
      Seen branch in repository origin/master
      Seen branch in repository origin/3.0.1
      Seen branch in repository origin/next.point
      Commencing build of Revision a2060dc86752c432eae0b81eb34ca18b0b5b858e (origin/3.0.1 )
      Checking out Revision a2060dc86752c432eae0b81eb34ca18b0b5b858e (origin/3.0.1 )
      [3.0.2] $ git checkout -f a2060dc86752c432eae0b81eb34ca18b0b5b858e
      [3.0.2] $ git tag -a -f -m "Hudson Build #19" hudson-3.0.2-19
      Recording changes in branch origin/3.0.1
      [3.0.2] $ git log --numstat -M --summary --pretty=raw a2060dc86752c432eae0b81eb34ca18b0b5b858e..a2060dc86752c432eae0b81eb34ca18b0b5b858e
      Triggering blah-3.0
      Triggering bleh-3.0
      Finished: SUCCESS
      

      Attachments

        Issue Links

          Activity

            magnayn magnayn added a comment -

            It should be an option, not the default though - since you can pull from many developer machines, if one is turned off, that shouldn't fail the build.

            magnayn magnayn added a comment - It should be an option, not the default though - since you can pull from many developer machines, if one is turned off, that shouldn't fail the build.
            jlongman jlongman added a comment -

            Yes it should. There's no need to have a continuous integration system if you're never going to update the source trees. I can't conceive of any argument where I would be happy if a build was started and I wasn't told the reason why the latest changes weren't used, in the strongest manner possible.

            At the _very_least_ the build should put a warning up. Anything less would continue without the real problem being solved, more specifically developers thinking their code works when it could be very very broken, and actually their repository is just unreachable.

            jlongman jlongman added a comment - Yes it should. There's no need to have a continuous integration system if you're never going to update the source trees. I can't conceive of any argument where I would be happy if a build was started and I wasn't told the reason why the latest changes weren't used, in the strongest manner possible. At the _very_least_ the build should put a warning up. Anything less would continue without the real problem being solved, more specifically developers thinking their code works when it could be very very broken, and actually their repository is just unreachable.
            eguess74 eguess74 added a comment -

            Agreed with jlongman
            Build should fail if there is no possibility to get the latest update and it should be default behavior. I believe there is only one repository configurable for the job and most of the time it will be the mainline, therefore if mainline is not accessible or update/fetch/merge has failed - it should fail the build.

            eguess74 eguess74 added a comment - Agreed with jlongman Build should fail if there is no possibility to get the latest update and it should be default behavior. I believe there is only one repository configurable for the job and most of the time it will be the mainline, therefore if mainline is not accessible or update/fetch/merge has failed - it should fail the build.
            eguess74 eguess74 added a comment -

            This is very important to fix, please, take a look as soon as possible

            eguess74 eguess74 added a comment - This is very important to fix, please, take a look as soon as possible
            eguess74 eguess74 added a comment -

            I took a freedom to reassign this to current maintainer.

            eguess74 eguess74 added a comment - I took a freedom to reassign this to current maintainer.
            abayer Andrew Bayer added a comment -

            Marking this as a duplicate, since I've already fixed this for JENKINS-6902.

            abayer Andrew Bayer added a comment - Marking this as a duplicate, since I've already fixed this for JENKINS-6902 .

            People

              abayer Andrew Bayer
              jlongman jlongman
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: