-
Notifications
You must be signed in to change notification settings - Fork 249
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
Hard to reach terraform_wrapper: false from CDKTF error #338
Comments
Hi @LumaKernel 👋 Thank you for reporting this and sorry you are running into trouble here. Could you please show us the full workflow configuration that led to this particular error? There have been some internal discussions previously about removing the Terraform wrapper as the default (leaving this action only responsible for installation and, potentially, another action for running commands in the GitHub Actions context with setting outputs, etc). |
Making it default-false at least sounds like an excellent idea - it's hard to discover that it's the cause even simply trying to use |
Hi there. Is any updates on this? const tempOutDir = Testing.fullSynth(terraformStack);
console.log(toBeValidTerraform(tempOutDir).message);
console.log(toPlanSuccessfully(tempOutDir).message); terraform 1.5.7
It works locally macOS Terraform v1.5.7 on darwin_amd64. |
This also leads for me to subsequent errors when using the CDK https://github.com/hashicorp/terraform-cdk-action Was hunting down for hours this problem until I realized that this problem is there. I was able to workaround this problem with |
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.
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.
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.
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.
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.
* 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 <[email protected]>
This issue will be fixed in an upcoming |
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. |
Situation
cdktf get
in GitHub ActionsHere is no hint to know when it gets
c
character while it's parsing JSON.I checked
handlers.js:94:49074
and I figured out that the original code is this.https://github.com/hashicorp/terraform-cdk/blob/49a7072948a115ef20ea5ebe62f8d04117de81c9/packages/%40cdktf/provider-generator/lib/get/generator/provider-schema.ts#L309-L313
Then I tried
terraform providers schema -json
in GitHub Actions and get it's wrapping the CLI.Now we get the character
c
is coming from[command]
Solution candidates
I have no right solution for this, but have ideas.
terraform_wrapper: false
terraform
which is not wrapped, and one anotherterraform-wrapped
which is wrappedNO_GHA_TERRAFORM_WRAP=1
, and setting this from CDKTF side to prevent this potential unrecognizable barrier for CDKTF starters.I like third solution. How about that?
The text was updated successfully, but these errors were encountered: