Skip to content
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

Open
Swatinem opened this issue Nov 25, 2020 · 2 comments · May be fixed by #1573
Open

[command]… output is prepended to exec outStream #649

Swatinem opened this issue Nov 25, 2020 · 2 comments · May be fixed by #1573
Labels
bug Something isn't working

Comments

@Swatinem
Copy link

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 the outStream, and not to stdout as I would expect.

To Reproduce
Steps to reproduce the behavior:

await exec.exec("echo", ["foobar"], { outStream: fs.createWriteStream("foobar.txt") });

Expected behavior
I want the foobar.txt file to only have foobar in it.
Instead, it will have the [command]echo foobar command output prepended.

Additional context

Not quite sure if this is intentional?

if (!optionsNonNull.silent && optionsNonNull.outStream) {
optionsNonNull.outStream.write(
this._getCommandString(optionsNonNull) + os.EOL
)
}

@Swatinem Swatinem added the bug Something isn't working label Nov 25, 2020
fearphage added a commit to glg-public/setup-ssh-agent that referenced this issue Aug 11, 2021
@fearphage
Copy link

It looks like the fix for this is to set the silent option to true, but that results in nothing being written to the outStream strangely.

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.
@OJFord
Copy link

OJFord commented Oct 26, 2023

An example(s) of this causing a problem in the wild are available at hashicorp/setup-terraform#367.

@OJFord OJFord linked a pull request Oct 26, 2023 that will close this issue
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
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants