Multiline `script:` is running without errexit?

Travis CI Discussions & Feedback
,
1

Hi Everyone,

We have a multiline script like:

script:
  - |
    if [[ "$TRAVIS_OS_NAME" == "linux" ]]; then
      ./configure
      make -j2
      make test
      ./custom-a.sh
    else
      ./configure
      make -j2
      make test
      ./custom-b.sh
    fi

The problem we are experiencing is, when configure, make and custom-x.sh fails the script continues to execute. For example, Job 154029345 fails during make, but then continues onto the make test (which fails), and then tries to run the self tests (which fails).

I’ve been trying to find the controlling document that explains multiline scripting, but I can’t find it at docs.travis-ci.com. (A link to the docs would be helpful).

How do we make the multiline script fail when the first command fails?

We know we can wrap everything in a top-level script that calls make, …, custom-b.sh. The problem is, we lose the output of custom scripts when they drop below the top level. So we want to keep everything at the top level so we can see the output.

For example, if we change this to:

    if [[ "$TRAVIS_OS_NAME" == "linux" ]]; then
      ./do-linux.sh
    else
      ...
    fi

with do-linux.sh:

#!/usr/bin/env bash

./configure
make -j2
make test
./custom-a.sh

then we lose configure and custom-a.sh output.

2

This is by design.
User commands run without errexit – because, by necessity, they are run with eval in the same shell as other build logic (so that environment changes they make are seen by further commands), so errexit would break the enveloping internal logic.

You have a few options here:

  • Put the commands into a separate script and run it (with -e or whatever), as a subprocess.

  • Invoke consecutive commands as

    cmd1 && \
cmd2 && \
etc

    so that the status of the first failed command propagates to exit status of the entire if compound command.

  • Run the block in a subshell with -e:

    - |
  (set -e
   <etc>
  )
3

I don’t understand what you mean here. This sounds not normal, but most probably, it’s a fault in the build logic or a confusion about how things are being logged. Please give an example if you wish to pursue this further.