-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
[command]…
output is prepended to exec outStream
#649
Labels
bug
Something isn't working
Comments
fearphage
added a commit
to glg-public/setup-ssh-agent
that referenced
this issue
Aug 11, 2021
It looks like the fix for this is to set the I worked around this by doing two separate commands: const { stdout } = await exec.getExecOutput(...);
fs.writeFile(filePath, stdout, options); |
OJFord
added a commit
to OJFord/toolkit
that referenced
this issue
Oct 26, 2023
Presently if the exec'd tool is expected to produce an output (i.e. to write to stdout) that can be consumed in a Unix pipeline, assigned to a variable, or similar; the `silent` option must be set in order to avoid the output being mangled by `@actions/exec` to include the full command string that it spawns. This commit writes the spawned command string to stderr instead of stdout, as would be expected for logging/debug information as opposed to consumable output data. Closes actions#649.
An example(s) of this causing a problem in the wild are available at hashicorp/setup-terraform#367. |
OJFord
added a commit
to OJFord/toolkit
that referenced
this issue
Oct 26, 2023
Presently if the exec'd tool is expected to produce an output (i.e. to write to stdout) that can be consumed in a Unix pipeline, assigned to a variable, or similar; the `silent` option must be set in order to avoid the output being mangled by `@actions/exec` to include the full command string that it spawns (and then re-writing out from the provided stdout listener). This commit writes the spawned command string to stderr instead of stdout, as would be expected for logging/debug information as opposed to consumable output data. Closes actions#649.
OJFord
added a commit
to OJFord/setup-terraform
that referenced
this issue
Oct 26, 2023
Presently using a command such as `terraform output -json | jq` does not work with the wrapper enabled, as it is by default. In order to consume terraform's output having set it up with this Action, it is necessary either to disable the wrapper (`with: terraform_wrapper: false`) or run it in its own Actions step with an explicit `id` (e.g. `id: foo`) so that it can be referred to and consumed (`${{steps.foo.outputs.stdout}}` et al.) in later steps. This seems to be the result of much confusion (issues passim) and is not at all easy (hashicorp#338) to debug/diagnose and come to the realisation that it's due to the wrapper, or even that such a thing exists. @austinvalle identified the issue as being due to the `@actions/exec` package writing the spawned command to stdout (along with then its actual stdout). This has previously been reported upstream in actions/toolkit#649; I've proposed actions/toolkit#1573 to fix it. This commit aims to address the issue for `setup-terraform` in the meantime by silencing `@actions/exec` and then writing out to stdout & stderr from the listener buffers, which it writes to without this additional logging. Closes hashicorp#20, hashicorp#80, hashicorp#85, hashicorp#149, hashicorp#338, and probably more.
OJFord
added a commit
to OJFord/setup-terraform
that referenced
this issue
Oct 26, 2023
Presently using a command such as `terraform output -json | jq` does not work with the wrapper enabled, as it is by default. In order to consume terraform's output having set it up with this Action, it is necessary either to disable the wrapper (`with: terraform_wrapper: false`) or run it in its own Actions step with an explicit `id` (e.g. `id: foo`) so that it can be referred to and consumed (`${{steps.foo.outputs.stdout}}` et al.) in later steps. This seems to be the result of much confusion (issues passim) and is not at all easy (hashicorp#338) to debug/diagnose and come to the realisation that it's due to the wrapper, or even that such a thing exists. @austinvalle identified the issue as being due to the `@actions/exec` package writing the spawned command to stdout (along with then its actual stdout). This has previously been reported upstream in actions/toolkit#649; I've proposed actions/toolkit#1573 to fix it. This commit aims to address the issue for `setup-terraform` in the meantime by silencing `@actions/exec` and then writing out to stdout & stderr from the listener buffers, which it writes to without this additional logging. Closes hashicorp#20, hashicorp#80, hashicorp#85, hashicorp#149, hashicorp#338, and probably more.
austinvalle
pushed a commit
to OJFord/setup-terraform
that referenced
this issue
Oct 27, 2023
Presently using a command such as `terraform output -json | jq` does not work with the wrapper enabled, as it is by default. In order to consume terraform's output having set it up with this Action, it is necessary either to disable the wrapper (`with: terraform_wrapper: false`) or run it in its own Actions step with an explicit `id` (e.g. `id: foo`) so that it can be referred to and consumed (`${{steps.foo.outputs.stdout}}` et al.) in later steps. This seems to be the result of much confusion (issues passim) and is not at all easy (hashicorp#338) to debug/diagnose and come to the realisation that it's due to the wrapper, or even that such a thing exists. @austinvalle identified the issue as being due to the `@actions/exec` package writing the spawned command to stdout (along with then its actual stdout). This has previously been reported upstream in actions/toolkit#649; I've proposed actions/toolkit#1573 to fix it. This commit aims to address the issue for `setup-terraform` in the meantime by silencing `@actions/exec` and then writing out to stdout & stderr from the listener buffers, which it writes to without this additional logging. Closes hashicorp#20, hashicorp#80, hashicorp#85, hashicorp#149, hashicorp#338, and probably more.
austinvalle
added a commit
to hashicorp/setup-terraform
that referenced
this issue
Oct 27, 2023
* Fix output malformed when wrapper enabled Presently using a command such as `terraform output -json | jq` does not work with the wrapper enabled, as it is by default. In order to consume terraform's output having set it up with this Action, it is necessary either to disable the wrapper (`with: terraform_wrapper: false`) or run it in its own Actions step with an explicit `id` (e.g. `id: foo`) so that it can be referred to and consumed (`${{steps.foo.outputs.stdout}}` et al.) in later steps. This seems to be the result of much confusion (issues passim) and is not at all easy (#338) to debug/diagnose and come to the realisation that it's due to the wrapper, or even that such a thing exists. @austinvalle identified the issue as being due to the `@actions/exec` package writing the spawned command to stdout (along with then its actual stdout). This has previously been reported upstream in actions/toolkit#649; I've proposed actions/toolkit#1573 to fix it. This commit aims to address the issue for `setup-terraform` in the meantime by silencing `@actions/exec` and then writing out to stdout & stderr from the listener buffers, which it writes to without this additional logging. Closes #20, #80, #85, #149, #338, and probably more. * add test for stdout with jq * update test name * remove debug lines and add changelog * add additional note about the bug fix to wrapper --------- Co-authored-by: Austin Valle <austinvalle@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I want to redirect a commands output to a file, but I still want the command that I execute to be logged.
Currently the
[command]…
log is streamed into theoutStream
, and not to stdout as I would expect.To Reproduce
Steps to reproduce the behavior:
Expected behavior
I want the
foobar.txt
file to only havefoobar
in it.Instead, it will have the
[command]echo foobar
command output prepended.Additional context
Not quite sure if this is intentional?
toolkit/packages/exec/src/toolrunner.ts
Lines 424 to 428 in 2bf7365
The text was updated successfully, but these errors were encountered: