Ability to choose a shell for scripts

[NickLarsenNZ]

What would you like to be added:

The ability to choose a shell for commands in TestAssert. For example:

---
apiVersion: kuttl.dev/v1beta1
kind: TestAssert
timeout: 600
commands:
  - shell: bash # runs bash -c instead of sh -c
    script: |
      set -euo pipefail
      ...
  - shell: bash -euo pipefail # runs bash -euo pipefail -c instead of sh -c
    script: |
      ...

Why is this needed:

• Currently sh -c is hard coded for shell invocations, and without options like -e to ensure failures before the last command get picked up.
• sh doesn't support setting -o pipefail to fail on errors in a pipeline.

[porridge]

What's worse, the behaviour of /bin/sh depends the environment. In some cases it is simply a symlink to bash, and then the bash features work. This reduces portability of tests. 😞

A couple of thoughts:

• it might be nice to not have to specify shell: bash -whatever in every single place, but instead provide the default in the config and have it trickle down automatically to all commands 🤔
• if we're going as far as allowing any shell, perhaps we should get rid of the assumption that -c is the way to pass the script to the shell, and instead rely on temporary files? 🤔

[NickLarsenNZ]

What's worse, the behaviour of /bin/sh depends the environment. In some cases it is simply a symlink to bash, and then the bash features work. This reduces portability of tests. 😞

Yeah, I'm having the problem where sh is a symlink to zsh, and zsh doesn't appear to treat sh as such - so the tests passed locally for me, but fail in CI which doesn't use zsh (unsure if it uses actual sh, or a symlink to bash - which as you say, treats it like sh).

if we're going as far as allowing any shell, perhaps we should get rid of the assumption that -c is the way to pass the script to the shell, and instead rely on temporary files? 🤔

Temporary files would be fine too, as you can then write them like a script with the shebang.

[porridge]

Temporary files would be fine too, as you can then write them like a script with the shebang.

The only potential issue would be that some folks might have /tmp mounted -o noexec 🤔 But I guess we could keep the current sh -c ... behaviour unless the text of script starts with #!?