-
Bug
-
Resolution: Duplicate
-
Critical
-
None
-
hudson version 337 (slave.jar also)
git version 1.6.3.2
git plugin version 0.7.3
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.
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
- duplicates
-
-
- Closed
-
[JENKINS-5216] Git plugin should fail build when fetch fails
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
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
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
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
added a comment - This is very important to fix, please, take a look as soon as possible eguess74
added a comment - I took a freedom to reassign this to current maintainer. Marking this as a duplicate, since I've already fixed this for JENKINS-6902.
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.