Terraform: remote-exec: "inline" with multiple commands succeeds despite failures if last command succeeded

[davidvartan]

Terraform Version

v0.9.4

Affected Resource(s)

• remote-exec with inline, tested on aws_instance

Terraform Configuration Files

Fails (expected):

provisioner "remote-exec" {
  inline = [
    "not_a_valid_command"
  ]

  connection {
    ...
  }
}

Fails (expected):

provisioner "remote-exec" {
  inline = [
    "not_a_valid_command",
    "touch /home/ec2-user/ok",
    "also_not_a_valid_command"
  ]

  connection {
    ...
  }
}

Does not fail (unexpected):

provisioner "remote-exec" {
  inline = [
    "not_a_valid_command",
    "touch /home/ec2-user/ok"
  ]

  connection {
    ...
  }
}

Debug Output

https://gist.github.com/davidvartan/ce32d7ed82222874ce094a508a77ba6b

(Search for not_a_valid_command in the output. Despite this, provisioning succeeds, and subsequent command still runs.)

Panic Output

N/A

Expected Behavior

If an inline command fails:

• Subsequent commands should not run (i.e. bash -e behavior)
• Provisioning should fail and instance marked tainted

Actual Behavior

• Provisioning succeeds if the last command in the inline block was successful.
• Checking the instance, it looks like the command after the invalid command was executed (i.e. can see the result of touch from my example).

Steps to Reproduce

• Use a remote-exec provisioner (with aws_instance in my case)
• Within the inline block, write an invalid command followed by a valid command.
• terraform apply

Important Factoids

N/A

References

N/A

[jantman]

FWIW, I can confirm that this is still valid with terraform 0.10.6

[DevOpsFu]

This was fixed by #11155 but was subsequently reverted. Related issue: https://github.com/hashicorp/terraform/issues/11145

[Tethik]

Also seeing this in Terraform v0.11.2

[MichaelPereira]

Not sure which version contained the fix before it was reverted, but we are also hit by this issue with Terraform 0.10.8.

I realize @mitchellh is quite busy these days, but if the original author @pmcatominey or reviewer @stack72 could provide a little context as to why it was reverted and if there is any plans to bring it back, it would be helpful to know how long we need workarounds for this problem.

Thanks

[pmcatominey]

Hi @MichaelPereira,

I wasn't aware that the change had been reverted, after looking on Github I can't find a corresponding PR to add context to why it was reverted.

The commit in question is 640faf1, from looking at the tags it has been reverted since 0.9.0.

Apologies for not being able to shine a light on the reasons, as a workaround you could instead use the script option and set shell options to exit when a command fails.

[mxork]

I'm actually OK with this behaviour, provided that it's documented. set -e as the first line, and it should abort as expected.

[grig-tar]

set -e works with linux, but what I should do with windows? script || exit 1 does not work

[che]

Doesn't work on v0.12.0-beta2.

set -e - also doesn't help