-
Improvement
-
Resolution: Unresolved
-
Major
-
None
-
Platform: All, OS: All
Occasionally something happens (network failure, someone shuts down the machine,
etc.) which makes a slave build fail. In this situation, currently Hudson gives
an exception like this:
hudson.util.IOException2: Failed to join the process
at hudson.Proc$RemoteProc.join(Proc.java:231)
at hudson.tasks.Ant.perform(Ant.java:180)
at hudson.model.Build$RunnerImpl.build(Build.java:138)
at hudson.model.Build$RunnerImpl.doRun(Build.java:113)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:244)
at hudson.model.Run.run(Run.java:842)
at hudson.model.Build.run(Build.java:88)
at hudson.model.ResourceController.execute(ResourceController.java:70)
at hudson.model.Executor.run(Executor.java:90)
Caused by: java.util.concurrent.ExecutionException:
hudson.remoting.RequestAbortedException: java.net.SocketException: Connection
reset
at hudson.remoting.Request$1.get(Request.java:165)
at hudson.remoting.Request$1.get(Request.java:134)
at hudson.remoting.FutureAdapter.get(FutureAdapter.java:32)
at hudson.Proc$RemoteProc.join(Proc.java:223)
... 8 more
This in itself is fine, but it then in turn marks the build as failed. This
results in Hudson thinking the changes which occurred for this build were the
cause for the build.
This causes two problems:
1. When the build is re-run and then works, Hudson won't list the changes
which occurred before the broken build as being changes which belong to the new
build.
2. If you are running the CI Game plugin, the unlucky soul who committed the
changes immediately before Hudson broke gets -10.0 points. IMO in this
situation the points should be docked against Hudson itself, or some other
equivalent placeholder player...
On a larger scale, any build which fails due to Hudson itself should not be
marked as failed for the same reason; this just happens to be the most common
situation which we encounter in practice.