scottwinkler / terraform-provider-shell

Terraform provider for executing shell commands and saving output to state file
Mozilla Public License 2.0
279 stars 61 forks source link

windows support and larger output fix #28

Closed scottwinkler closed 4 years ago

scottwinkler commented 4 years ago

This is a pretty major overhaul to how the RunCommand() works. The purpose of this is to solve ticket #26, as well as getting rid of the dependency on outputting to device 3 so that the provider will work on Windows (as Windows does not support ExtraFiles for the run command).

Instead of printing to >&3, now you print directly to stdout. The stdout and stderr channels log to the same place for streaming purposes, but now all the output is segregated so that it can be processed later. This fixes the issue with ticket #26 which caused the provider to hang if there was too much output trying to be read at once. In the stdout string, it is parsed to determine if there is a JSON string in the output. It will match against the last one, and use this to construct the map[string]string that gets output to Terraform. Tests have been updated to reflect changes and all tests are now passing. Below is an example data source that removes the need for printing to >&3

data "shell_script" "user" {
    lifecycle_commands {
        read = <<-EOF
          echo "{\"user\": \"$(whoami)\"}"
        EOF
    }
}

If you like this change then please leave a thumbs up. It's a breaking change so it will require a major version change.

lachatak commented 4 years ago

I really appreciate your effort and your quick reaction! I have tested the code in my own context and it does what I expected to get. Thank you very much!

pacon-vib commented 4 years ago

Please take a look at my fork of this branch: https://github.com/pacon-vib/terraform-provider-shell/tree/feature/no-device-3. I've amended the examples to print state to stdout instead of fd 3. I've also added a couple of examples which explore the behaviour of the revised provider.

Reading state from stdout works quite well. The way I write scripts to run under this provider, I prepare the state string in a variable and then the last thing the script does is emit state. As illustrated in the trailing-space example, it is possible to write a script which trips up state detection if you really try, but in practice it is highly unlikely that there will be spurious output after state.

lachatak commented 4 years ago

@scottwinkler Do you have ideas when this issue can be resolved?

scottwinkler commented 4 years ago

My apologies on the delay. It's not a difficult set of changes. I will try to get it done tomorrow, or else the day after