Cirrus-ci-docs: ci passes when it fails to find command

[MarcoFalke]

In an empty repository with just .cirrus.yml, the following script passes even though it fails to find the commands:

  ci_script:
    - ci_test_run && ci_test_run2 foo -y
    - ls

For example: https://cirrus-ci.com/task/6478729159376896?command=ci#L1

[fkorotkov]

This is very weird. Without && it's working as expected. 😲Investigating further.

[fkorotkov]

Seems it's an expected behaviour when set -e is used to stop on the first failure (which is used by Cirrus CI Agent): https://unix.stackexchange.com/questions/312631/bash-script-with-set-e-doesnt-stop-on-command

Investigating how to workaround it.

[fkorotkov]

I wasn't able to find a workaround. It's a very weird behaviour of set -e in bash and I'm not sure what can be done on Cirrus side. 😪

[Minoru]

@fkorotkov Can Cirrus wrap every command in the script like this: ( CMD ) || false? (Parentheses needed to make sure that any failure at any stage in the CMD will lead to false)

[MarcoFalke]

I think that wouldn't work when CMD is export FOO=bar

[Minoru]

Curly braces, then (note the semicolon is required; note that two semicolons in a row would be syntax error): { CMD ; } || false.

Also, false always returns 1, so || false will gobble up the exit code of the CMD. To pass it through, we do this: { CMD ; } || exit $?.

[fkorotkov]

IMO it seems to "magical" and I'm afraid of some other side effects when there is a custom $CIRRUS_SHELL specified for example. This behaviour took me by surprise and this wasn't noted by anyone before (at least to my knowledge). I feel we just need to live with this. You could experience the same issue in you own script.

[Minoru]

Oh, I wasn't aware that users can specify a custom shell. Fair enough :+1: