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

Problem with stdout, from terraform output command #149

Closed
mmor0130 opened this issue Feb 22, 2022 · 4 comments
Closed

Problem with stdout, from terraform output command #149

mmor0130 opened this issue Feb 22, 2022 · 4 comments

Comments

@mmor0130
Copy link

We have three steps each with a terraform output command, and only one output works as expected.

- name: Get address space
      id: get_address_space
      run: terraform output -json address_spaces

- name: get git tag
      id: get_git_tag
      run: terraform output git_tag_version

- name: Get Firewall Group Policy Priority Number
      id: get_policy_number
      run: terraform output rule_collection_group_priority

This should output respectively

["10.2.1.0/26"]
"0.0.1"
504

When we try to reference the output in another step, like this:

- name: Echo output
  run: |
    echo ${{ steps.get_address_space.ouputs.stdout }}
    echo ${{ steps.get_git_tag.ouputs.stdout }}
    echo ${{ steps.get_policy_number.outputs.stdout }}

the result is empty except for 'get_policy_number', which correctly give 504.

The output variable types in terraform are:

["10.2.1.0/26"] = list(string)
"0.0.1" = string
504 = number

What are we missing? Do we have to do anything else, when output is a string?

@kapilt
Copy link

kapilt commented Mar 11, 2022

running into the same issue, terraform output -json -no-color seems to get corrupted and isn't valid json.

@kapilt
Copy link

kapilt commented Mar 11, 2022

found a ref to setting this flag which will do the right thing.

        terraform_wrapper: false

OJFord added a commit to OJFord/setup-terraform that referenced this issue Oct 25, 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.

This commit aims to address the issue by passing through stdout &
stderr, so that they're available in Unix pipelines and variable
assignment etc. as expected within a single step, while still retaining
the wrapper's listening behaviour to provide them as Actions outputs.

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 25, 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.

This commit aims to address the issue by passing through stdout &
stderr, so that they're available in Unix pipelines and variable
assignment etc. as expected within a single step, while still retaining
the wrapper's listening behaviour to provide them as Actions outputs.

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

This issue will be fixed in an upcoming v3.0.0 release next week. Please see this comment for more info

Copy link

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 23, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants