If Jenkins slaves disconnect, their builds are considered failed. So, a
possible solution would be to not actually run the build that can cause a
disconnect on a Jenkins slave.
Let's say your job involves running a Maven build.
Usually, you'd have a Maven build step, or a shell step with a command like the
following running on the machine you're using (let's call it 'A'):
mvn clean install
Assuming you're using an OS that comes with SSH, just run the command through
an SSH connection to A on another host B:
ssh user@A mvn clean install
In case of a disconnect, SSH returns with return code 255. If that's the case,
add any necessary handling of that case to the build script running on the
other machine (B), like waiting a minute, then gathering the log file.
ssh user@A bash -c 'mvn clean install | tee buildlog.txt
_rc=$?
# exit without error when it finished successfully
[[ $_rc -ne 0 ]] || exit 0
# exit with error when something other than SSH went wrong
[[ $_rc -ne 255 ]] || exit $_rc
# otherwise wait a minute, then reconnect and get the log
sleep 60
echo "Full build log:"
ssh user@A cat buildlog.txt
Now this is just a rough sketch of a solution and much more needs to be done to
make this useful, but that really depends on the exact behavior you want.
Needless to say, you won't have many of the conveniences of using Jenkins
(automatically allocated workspace, SCM checkout, ...) this way.
On 10.03.2014, at 09:20, EK <eyas.ko...@gmail.com> wrote:
> Can you please give more details ? not sure if I understand how to do what
> you have suggested ?
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
