Correctly capture failures from the Subshell #103
Conversation
Currently the -e option is turned off from inside the subshell - This fails though, as it remains on for the parent shell. Thus, to capture (and handle) failures, we need to turn the option off in the top level shell correctly, rather than in a child shell, and restore this *after* our block of code has been run.
|
Thanks for this! I noticed that this was happening the other day and was trying to write some tests to prove what was going on. I'm going to try and commit those tests first to prove the breakage. |
|
I'm going to merge this and add tests later. Thanks again @Sutto. |
|
No problem! Thanks for looking at it so quickly. I also noticed that it's possible for the docker logs to fail in some cases - so it might be worth wrapping that with the same trick / ignoring their exit code (or else cleanup will be invoked early). |
Do you mean |
|
Sorry, I missed your reply - yep. It's possible if a container had no output that it will exit with a non-zero error code - and likewise, it double prints the output (since it runs and prints to stdout, then uploads the artifact) - for the main container run. |
|
Ah yup, I noticed that too. I'll look into it. Cheers @Sutto. |
Currently the -e option is turned off from inside the subshell - This fails though, as it remains on for the parent shell.
Thus, to capture (and handle) failures, we need to turn the option off in the top level shell correctly, rather than in a child shell, and restore this after our block of code has been run.
This manifests itself in the form of failed commands only invoking cleanup, and none of the rest of the code. The check on exit code is completely skipped and, for instance, docker logs from linked containers are never uploaded (which is far from ideal).