29

In our project we have a shell script which is to be sourced to set up environment variables for the subsequent build process or to run the built applications.

It contains a block which checks the already set variables and does some adjustment.

# part of setup.sh
for LIBRARY in "${LIBRARIES_WE_NEED[@]}"
do
  echo $LD_LIBRARY_PATH | \grep $LIBRARY > /dev/null
  if [ $? -ne 0 ]
  then
   echo Adding $LIBRARY
   LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$LIBRARY
  else
   echo Not adding $LIBRARY
  fi
done

i.e. it checks if a path to a library is already in $LD_LIBRARY_PATH and if not, adds it. (To be fair, this could be written differently (like here), but assume the script is supposed to achieve something which is very hard to do without calling a program, checking $? and then either doing one thing or doing another thing).

The .gitlab-ci.yml then contains

before_script:
  - yum install -y <various packages>
  - source setup.sh

but the runner decides to stop the before script the very moment $? is non-zero, i.e. when the if-statement decides to add a path to $LD_LIBRARY_PATH. Now it is nice that the gitlab runner checks $? after each line of my script, but here it'd be great if the lines in .gitlab-ci.yml were considered atomic.

Is there a way to avoid the intermediate checks of $? in a script that's sourced in .gitlab-ci.yml?

Community
  • 1
  • 1
pseyfert
  • 3,263
  • 3
  • 21
  • 47
  • This question is relevant if you are getting `ERROR: Job failed: Process exited with status 1` without any other clue. Added comment for future searches. – Yariv Nov 23 '21 at 10:16

2 Answers2

53

Use command_that_might_fail || true to mask the exit status of said command.

Also note that you can use grep -q to prevent output:

echo "$LD_LIBRARY_PATH" | grep -q "$LIBRARY" || true

This will however also mask $? which you might not want. If you want to check if the command exits correct you might use:

if echo "$LD_LIBRARY_PATH" | grep -q "$LIBRARY"; then
  echo "Adding $LIBRARY"
else
  ...
fi

I suspect that gitlab-ci sets -e which you can disabled with set +e:

set +e # Disable exit on error
for library in "${LIBRARIES_WE_NEED[@]}"; do
  ...
done
set -e # Enable exit on error

Future reading: Why double quotes matter and Pitfalls with set -e

Andreas Louv
  • 46,145
  • 13
  • 104
  • 123
25

Another trick that I am using is a special kind of "|| true", combined with having access to previous exit code.

- exit_code=0
- ./myScript.sh || exit_code=$?
- if [ ${exit_code} -ne 0 ]; then echo "It failed!" ; else echo "It worked!"; fi

The $exit_code=$? always evaluates to "true" so you get a non failing command but you also receive exit_code and you can do whatever you want with it.

Note please, that you shouldn't skip the first line or exit_code will be uninitialized (since on successful run of script, the or'ed part is never executed and the if ends up being)

if [ -ne 0 ];

instead of

if [ 0 -ne 0 ];

Which causes syntax error.

Martin
  • 4,170
  • 6
  • 30
  • 47
Marcin K.
  • 683
  • 1
  • 9
  • 20
  • Note that you'll need to reset the variable everytime you need it, as the assignment will only happen if the command fails. Something like `exit_status=0; ./myscript.sh || exit_status=$?` – Andreas Louv Jan 27 '22 at 15:35
  • 2
    Please just make it a habit to always wrap your parameter expansions in double quotes: `[ "$exit_status" -ne 0 ]` if the parameter is empty it will expand to an empty argument for the `[` command, instead of evaporating. It will also prevent word splitting and pathname expansion. – Andreas Louv Jan 27 '22 at 15:37