Travis_retry on windows does not make the build fail

Environments Windows
1

Hi,
I’ve noticed that sourceing a script that’s supposed to fail and surrounding it with travis_retry under Windows falsely makes the build successful.
Here is a (correctly) failing build: https://travis-ci.org/DanySK/travis-testing-playground/builds/645951337?utm_medium=notification&utm_source=email
And here a “fixed” build, with the same bad script executed with travis_retry: https://travis-ci.org/DanySK/travis-testing-playground/builds/645964922?utm_medium=notification&utm_source=email

It apparently ignores set -e.

2

I don’t think this is a question of Linux vs Windows; they both behave similarly.

I think there is a bug in the function itself, but I am not exactly sure where.

You seem to be correct when you point out that set -e is ignored, but I have not been able to reason why, or reproduce in a different context.

3

That’s a well-known bug-feature (read: obscure shenanigan :stuck_out_tongue:) of Bash.

If a command is allowed to fail (suffixed with || or is within if condition), errexit in it is effectively disabled, and even setting it explicitly has no effect.

See BashFAQ/105 - Greg’s Wiki for details.

$ (set -e;
> set -o | grep errexit
> (set -o | grep errexit; set -e; set -o | grep errexit; false; echo "unexpected") || true;
> )
errexit         on
errexit         on
errexit         on
unexpected

The best mitigation that I found is suffixing every command in a block that’s expected to run in this “mode” with || exit $? (|| return $? if in a function).

4

It is possible to edit the function to run the command in a way that doesn’t invoke this “mode”, using the fact that Travis’ logic runs without errexit:

Note though that since user commands are run in the current shell (by necessity as shell environment changes they make must persist for the following commands), exiting via -e will terminate the entire job immediately (not running stages like cache save), and you may not get full output unless you call travis_terminate upon exit.

1 Like
5

I thought I knew a decent amount about bash. :see_no_evil:

1 Like
6

Well, maybe I exaggerated its fame a little :stuck_out_tongue:

7

I’ve merged the PR. This allows some reasonable workaround for the unexpected result. Since we are unable to overcome the errexit issue, I’ll advise you to concoct your own mechanism to deal with the error(s) inside your own sourced file.

8

If the change is up and running, then I guess that the strange behaviour should be fixed now: why do you suggest to concoct my own mechanism?
My tests fail successfully (LOL).