> there will be no error output, you won't know why it failed
That's probably why the -x is there. (Well, that and if something like curl or sudo fails it tends to output something to stderr...)
> Pipefail also doesn't prevent more complex error states ... A corrupt executable is left on-disk (which will be attempted to run if your step had failure-skipping enabled)
If I'm reading right it seems like you're suggesting is that the case pipefail doesn't handle is if you explicitly ignore the exit code. That doesn't exactly seem like the most concerning catch 22, to be honest.
-x does not show output/errors when pipefail triggers. It tells you a pipe has started, and that's it. No idea what specific part of the pipe failed, or why, or what its return status was.
It's not that pipefail doesn't handle a case, it's that it doesn't tell you what happened. It does not report what failed or why. Your shell just exits with a mystery return code.
The point is that if you run -x you will definitely see plenty of output leading up to the failure. It is true that if the command that fails outputs nothing to stderr, then this may still lead to confusing outcomes, but you will not be staring at empty output, you'll be staring at the commands leading up to the failure.
This is of course no different than if you had set -e and then a command with no pipes failed silently without outputting anything to stderr.
I don't personally see why this is notable in relation to pipefail.
That's probably why the -x is there. (Well, that and if something like curl or sudo fails it tends to output something to stderr...)
> Pipefail also doesn't prevent more complex error states ... A corrupt executable is left on-disk (which will be attempted to run if your step had failure-skipping enabled)
If I'm reading right it seems like you're suggesting is that the case pipefail doesn't handle is if you explicitly ignore the exit code. That doesn't exactly seem like the most concerning catch 22, to be honest.