-
-
Notifications
You must be signed in to change notification settings - Fork 612
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Task file commands with pipe (|) in them don't fail #392
Comments
Hi @brodster2, thanks for opening this issue! In my tests, the behavior of Bash and Task are the same: Regarding The only difference I found is that Bash support |
@andreynering can you explain why this only works for single line scripts? I used your provided workaround successfully with cmd1:
cmds:
- set -o pipefail ; aws something | jq .someField
- echo success # this never happens if aws fails
cmd2:
cmds:
- |
set -e
set -u
set -o pipefail
aws something | jq .someField
echo success # happens despite error in the aws command |
This is not a problem with Task directly. Please report https://github.com/mvdan/sh. Notice also that there are other differences in your script, not just the lack of newline characters, but also the lack of semicolons. This is definitely not a task specific problem though. |
Is there a way to cmd1:
cmds:
- set -e -o pipefail; do-something-1 | foo
- set -e -o pipefail; do-something-2 | bar
- set -e -o pipefail; do-something-3 | baz It would be nice to have the possiblity to do the cmd1:
cmds:
- set -e -o pipefail
- do-something-1 | foo
- do-something-2 | bar
- do-something-3 | baz But this seems to fully ignore the first cmd. |
Look into #908. All commands run in isolation so the variable is not set in all cmds |
Using task version 3
MacOS and Linux
When using a task that runs a command that includes a pipe (
|
) the task does not fail if the first part of the command fails.Example Taskfile.yml
Output:
It still doesn't fail the task if I call task from a script that sets pipefail
I have also tried:
but still get the same result
I couldn't see anything in the documentation about changing this behaviour, so I guess it's a bug?
The text was updated successfully, but these errors were encountered: