mirror of https://github.com/hashicorp/terraform
The terraform.workspace attribute is a rare example of a CLI- and Cloud- specific concern bleeding into the Terraform language, and it can only really have meaning when used in the traditional Terraform workflow because otherwise there's no workspace to return the name of. In Stacks any variations between instances of a module must be created through input variables. Within Terraform Cloud in particular it's also possible to use stack-level input variables that are assigned different values from different stack deployments, and thus an author can recreate the effect of terraform.workspace using a stack-level input variable that has a different value for each deployment. This is one of the few cases where the Terraform module language differs in stacks compared to traditional Terraform. Any module that makes use of terraform.workspace will need to be generalized to use input variables instead before it can be used within a stack component. Prior to this change, references to terraform.workspace from a module used in a stack component would just panic altogether, because the stacks runtime doesn't provide the object that the workspace name would be taken from. Now we'll return a user-oriented error instead.RK/fix-nav-upgrade-name
parent
9851cd456e
commit
0994e6fbf9
@ -0,0 +1,6 @@
|
||||
output "invalid" {
|
||||
# terraform.workspace is not available when this module is used as part
|
||||
# of a stack component, so this should produce an error during
|
||||
# planning.
|
||||
value = terraform.workspace
|
||||
}
|
||||
@ -0,0 +1,3 @@
|
||||
component "mod" {
|
||||
source = "./"
|
||||
}
|
||||
Loading…
Reference in new issue