redesign / refactor `run` nodes which are succeeding on non-zero exit codes.

[briandorsey]

Running multiple commands in the same "run" node can hide failures (non zero exit codes) in early commands.

As identified in #30 :
"the panic returns exit 2, but being wrapped in an echo means action steps exits successfully.

Example:

cloud-samples-tools/actions/steps/affected/action.yaml

Line 96 in 9ae10d7

run: |

This is a tracking issue to consider different ways to improve this pattern so that non-zero exit codes result in the step failing.

[briandorsey]

Without looking into it deeper, it's unclear to me if this only happens when multiple commands are in the run node, or if the echo pattern (that GH uses in a bunch of their Actions docs) always swallows the non-zero exit code.

[grayside]

According to https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#defaultsrunshell, when bash is specified as the shell, the command used is bash --noprofile --norc -eo pipefail {0}. I found -e sufficient that the following crashed on x assignment every time:

echo "Return an error, then output if we keep going: ..."
x=$(exit 1)
echo "Kept going"

(We may want to consider more intense strictness as a default: set -Eeuo pipefail)

However, even with maximum strictness, the following always succeeded:

echo "Echo an error, then output if we keep going: ..."
echo "$(false)"

With this reproduction, maybe fixing this is as simple as separating running the subshell command from echoing the result:

set -v
setupFiles=$(custard setup-files ${{ inputs.config-file }} paths.txt)
# If output in the log is helpful
# echo "custard setup-files:\n${setupFiles}
echo "ci-setups=${setupFiles}" >> $GITHUB_OUTPUT