@senui,

I forked your repository and tested. According to my troubleshooting, I found the error returned from the command line “$INSTALL_DIR/bin/thisbdm.sh”.
The error did not occur on this command line itself. It should be returned by a certain command line in the script ‘thisbdm.sh’.

I recommend that you can try to check if the command lines in the script ‘thisbdm.sh’ contain some defects, and also try executing this script on your local environment to see if it can work fine.

Hi @brightran,

Thanks for your reply. Could you please tell me how you managed to find out that the error originated from $INSTALL_DIR/bin/thisbdm.sh?

We are running the same type workflow on Ubuntu 18.04, 20.04, and on macOS, but without any failures there…

Yes, I could check the command lines in the thisbdm.sh script one-by-one and I could try executing the script locally to debug this, but as I tried to make clear in my opening post, this could potentially cost me hours and hours of work.

Why is it not possible to see in the Github Actions output which line of thisbdm.sh returned a non-zero exit code? If you run any bash script normally in a terminal, it should output the error message, and not try to hide it.

I hope that there is some more convenient way to debug this vague failure.

Edit:
I just tried running the exact same commands in the same CentOS docker container that the failing workflow is using, and I cannot reproduce the error 😦

@senui,

Could you please tell me how you managed to find out that the error originated from $INSTALL_DIR/bin/thisbdm.sh ?

In the “System tests BioDynaMo” step, I printed a label after each command line executed successfully, and found the label for the line “$INSTALL_DIR/bin/thisbdm.sh” did not print. So I could locate the command line where the error was returned from.

For this issue, I have created an issue ticket (actions/virtual-environments#1279) to help you report it.
You can follow this issue ticket and add you comment on it.

Thanks for opening the issue ticket. I hope the team understands that the absence of an error message makes this a non-trivial debugging issue. I will keep an eye on the ticket

@senui,

OK, please keep following the issue ticket.

Hi @al-cheb,

Many thanks for investigating the issue at hand!

Although I believe that the line that you marked with “failed line” is by design supposed to return a non-zero exit code if $arg is not enabled. In which case, any script that uses non-zero return codes as a means to implement some logic will always fail a Github Action workflow…

Is this something you guys at Github considered? Will things stay like this?

Furthermore, it is strange that this was not reproducible on the same docker container on my own machine. Do you have any idea why this only fails on GH Actions?

@senui,

Case with source:
The /usr/bin/scl_enabled llvm-toolset-6.0 encounters a exit 1 which is different from zero. It will terminate the scl_source code instantaneously due to the exit statement and that’s why:
. $INSTALL_DIR/bin/thisbdm.sh - failed and $INSTALL_DIR/bin/thisbdm.sh - works

Looks like it by design:

return [n]

Causes a function to exit with the return value specified by n. If used outside a function, but during execution of a script by the . (source) command, it causes the shell to stop executing that script and return either n or the exit status of the last command executed within the script as the exit status of the script. If used outside a function and not during execution of a script by ., the return status is false.

source filename [arguments]
    Read and execute commands from filename in the current shell environment and
    return **the exit status of the last command executed from filename**. 

Is there a difference between "." and "source" in bash, after all?

Reproduce behavior:

Without source( ./test.sh):

steps:
      - name: Test
    run: |
      cat <<EOF > $HOME/subscript.sh
      #!/bin/sh
      exit 1
      EOF
      chmod +x $HOME/subscript.sh
      
      cat <<EOF > test.sh
      #!/bin/bash
      $HOME/subscript.sh
      if [ $? -ne 0 ]; then
          echo PASS
      fi;
      EOF
      
      chmod +x ./test.sh
      echo START
      ./test.sh
      echo END

With source(source ./test.sh):

steps:
      - name: Test
    run: |
      cat <<EOF > $HOME/subscript.sh
      #!/bin/sh
      exit 1
      EOF
      chmod +x $HOME/subscript.sh
      
      cat <<EOF > test.sh
      #!/bin/bash
      $HOME/subscript.sh
      if [ $? -ne 0 ]; then
          echo PASS
      fi;
      EOF
      
      chmod +x ./test.sh
      echo START
      source ./test.sh
      echo END

With source || true (source ./test.sh || true):

    steps:
      - name: Test
    run: |
      cat <<EOF > $HOME/subscript.sh
      #!/bin/sh
      exit 1
      EOF
      chmod +x $HOME/subscript.sh
      
      cat <<EOF > test.sh
      #!/bin/bash
      $HOME/subscript.sh
      if [ $? -ne 0 ]; then
          echo PASS
      fi;
      EOF
      
      chmod +x ./test.sh
      echo START
      source ./test.sh || true
      echo END

Hi @al-cheb,

Thanks for the clear explanation. I understand the situation better now, and will keep this in the back of my mind if I ever get a non-zero exit code again!

Thanks,
Ahmad