Hi @Vin_Rao,
I think first it’s important to think about the differences between data resources (data blocks) and managed resources resource blocks).
During the planning phase Terraform treats these quite differently:
-
For managed resources, Terraform evaluates the configuration and passes it to the relevant provider to ask it to predict what the new state would be if that configuration were applied. If the provider is written correctly then this should make no changes to your real infrastructure.
Provisioners (provisioner blocks) are declared inside a resource block but are a special concept belonging to Terraform itself, not to any particular provider. Aside from some basic type checking and argument name validation, provisioner blocks have absolutely no effect during the planning phase.
-
For data resources, Terraform evaluates the configuration but then does one of two things depending on the result:
- If the configuration contains any values that won’t be known until the apply phase – shown as
(known after apply) in the plan description – Terraform concludes that it cannot read the data during the plan phase and so it instead just remembers that it will need to read the data during the apply phase.
- If the configuration is entirely known values and the data resource doesn’t depend on any managed resources that have pending changes, Terraform immediately reads the data source during the plan phase and uses its results for the remainder of the planning work. It will not read the data again during the apply phase.
Failure of either the planning request for a managed resource or the read request for a data resource will halt Terraform’s work and prevent taking any further actions for dependent resources, but this means you must make sure that the action that might fail does actually happen during the planning phase.
The hashicorp/external provider’s external data source implements “reading” by executing the program you specify and then parsing the result as JSON. If the program exits with a non-zero exit status then the provider will consider it to be a planning error.
Your data "external" block uses only static constant values as arguments, so Terraform should always be able to read from this data source during the planning phase.
Based on your example it seems like you’ve implemented C:/terraform/LocalPSMinMaxMatch-2.ps1 as a program that always succeeds but sets a valuesMatch property in its JSON response, which I assume is set either to "true" or "false" depending on the outcome.
That declaration alone will not prevent any further execution because returning "false" is still a successful result. There are two main ways you can make that data resource fail:
-
Change your script to exit with a non-zero status when the values don’t match, instead of printing a JSON object that sets a property to "false". Anything which depends on that data resource will be blocked from being evaluated if the program fails.
-
Keep your program as-is but add a postcondition which tells Terraform that the data source result is only valid if valuesMatch is "true":
data "external" "min_max_values_match" {
program = [
"powershell.exe",
"-ExecutionPolicy",
"Bypass",
"-File",
"C:/terraform/LocalPSMinMaxMatch-2.ps1",
]
lifecycle {
postcondition {
condition = data.external.min_max_values_match.result.valuesMatch
error_message = "Values do not match."
}
}
}
The lifecycle block and everything inside it is handled by Terraform Core and is valid for all data blocks, regardless of resource type. After reading from this data source, Terraform will evaluate the condition expression. If its result converted to a boolean is false then it will halt and show the error_message.
You will need to write depends_on = [data.external.min_max_values_match] inside any resource or data block whose evaluation should be blocked by an error. That will then guarantee that those downstream resources cannot be evaluated if the postcondition fails.
The postcondition is effectively an extra check that can potentially return an error based on custom rules written in your module, without any need to modify the data source implementation itself.
I think using a data block is probably the better option here because it can be dealt with during the planning phase, but you’ll need to make one of the changes I described above to get the effect you want.
If you want to do this with a local-exec provisioner then that’s also valid but because provisioners only run during the apply phase (after the object has actually been created) you can only cause errors during the apply phase by this technique.
To make this work you will need to make sure that the command you run returns a non-zero exit status when it fails. The echo do_values_match command you showed in your example will always succeed, so it cannot possibly block progress.
Again you will need to use depends_on with any resource whose execution should be blocked by the error. Since provisioners are an apply-time feature, a provisioner cannot block another resource from having actions planned, but it can block a resource from having its planned actions executed during the apply phase.
