IntenseWebs/opentofu
3
0
Fork 0
mirror of https://github.com/opentofu/opentofu.git synced 2025-01-02 12:17:39 -06:00
Code Issues Packages Projects Releases Wiki Activity
5b9f2fafc8
opentofu/terraform/testdata/apply-provisioner-interp-count/provisioner-interp-count.tf

18 lines
419 B
Terraform
Raw Normal View History

update test fixtures Update test fixtures to work in our new world. This is mostly changing out attribute names for those in the schema, adding Providers to states, and updating the test-fixture configurations.
2018-05-23 12:39:36 -05:00
variable "num" {
core: interpolate the count config during the apply walk Previously we would interpolate the count config (ResourceConfig.RawCount) only while preparing to dynamic-expand aggregate resource nodes. This is problematic because we do not dynamic-expand any resource nodes during the apply walk, and so previously the count value was not available for interpolation during apply and would result in an error. Now we interpolate RawCount once for each resource we visit during the apply walk -- even though that redundantly interpolates the same config multiple times when count > 1 -- to ensure that it's available by the time we interpolate any remaining expressions in the config and any expressions within "connection" and "provisioner" blocks. This error was masked by us sharing a single RawConfig instance between the plan and apply walks when "terraform apply" is run with no explicit plan file argument, but was exposed by the workflow where the plan is written first to disk since in that case the interpolation result from during the plan phase is not present in the deflated plan object. For this reason, the new context test serializes the plan into an in-memory buffer and reloads it in order to simulate the effect of the two-step workflow.
2018-01-17 17:27:17 -06:00
default = 3
}
resource "aws_instance" "a" {
core: Fix TestContext2Apply_provisionerInterpCount This was relying on a no-longer-valid mechanism for accessing the "count" value from a resource block. The original issue this test was written to cover is not really such a sharp edge anymore, since the length is taken from the state during apply rather than from configuration, but it's still a good case to cover.
2018-09-26 13:45:35 -05:00
count = var.num
core: interpolate the count config during the apply walk Previously we would interpolate the count config (ResourceConfig.RawCount) only while preparing to dynamic-expand aggregate resource nodes. This is problematic because we do not dynamic-expand any resource nodes during the apply walk, and so previously the count value was not available for interpolation during apply and would result in an error. Now we interpolate RawCount once for each resource we visit during the apply walk -- even though that redundantly interpolates the same config multiple times when count > 1 -- to ensure that it's available by the time we interpolate any remaining expressions in the config and any expressions within "connection" and "provisioner" blocks. This error was masked by us sharing a single RawConfig instance between the plan and apply walks when "terraform apply" is run with no explicit plan file argument, but was exposed by the workflow where the plan is written first to disk since in that case the interpolation result from during the plan phase is not present in the deflated plan object. For this reason, the new context test serializes the plan into an in-memory buffer and reloads it in order to simulate the effect of the two-step workflow.
2018-01-17 17:27:17 -06:00
}
resource "aws_instance" "b" {
provisioner "local-exec" {
core: Fix TestContext2Apply_provisionerInterpCount This was relying on a no-longer-valid mechanism for accessing the "count" value from a resource block. The original issue this test was written to cover is not really such a sharp edge anymore, since the length is taken from the state during apply rather than from configuration, but it's still a good case to cover.
2018-09-26 13:45:35 -05:00
# Since we're in a provisioner block here, this expression is
core: interpolate the count config during the apply walk Previously we would interpolate the count config (ResourceConfig.RawCount) only while preparing to dynamic-expand aggregate resource nodes. This is problematic because we do not dynamic-expand any resource nodes during the apply walk, and so previously the count value was not available for interpolation during apply and would result in an error. Now we interpolate RawCount once for each resource we visit during the apply walk -- even though that redundantly interpolates the same config multiple times when count > 1 -- to ensure that it's available by the time we interpolate any remaining expressions in the config and any expressions within "connection" and "provisioner" blocks. This error was masked by us sharing a single RawConfig instance between the plan and apply walks when "terraform apply" is run with no explicit plan file argument, but was exposed by the workflow where the plan is written first to disk since in that case the interpolation result from during the plan phase is not present in the deflated plan object. For this reason, the new context test serializes the plan into an in-memory buffer and reloads it in order to simulate the effect of the two-step workflow.
2018-01-17 17:27:17 -06:00
# resolved during the apply walk and so the resource count must
core: Fix TestContext2Apply_provisionerInterpCount This was relying on a no-longer-valid mechanism for accessing the "count" value from a resource block. The original issue this test was written to cover is not really such a sharp edge anymore, since the length is taken from the state during apply rather than from configuration, but it's still a good case to cover.
2018-09-26 13:45:35 -05:00
# be known during that walk, even though apply walk doesn't
core: interpolate the count config during the apply walk Previously we would interpolate the count config (ResourceConfig.RawCount) only while preparing to dynamic-expand aggregate resource nodes. This is problematic because we do not dynamic-expand any resource nodes during the apply walk, and so previously the count value was not available for interpolation during apply and would result in an error. Now we interpolate RawCount once for each resource we visit during the apply walk -- even though that redundantly interpolates the same config multiple times when count > 1 -- to ensure that it's available by the time we interpolate any remaining expressions in the config and any expressions within "connection" and "provisioner" blocks. This error was masked by us sharing a single RawConfig instance between the plan and apply walks when "terraform apply" is run with no explicit plan file argument, but was exposed by the workflow where the plan is written first to disk since in that case the interpolation result from during the plan phase is not present in the deflated plan object. For this reason, the new context test serializes the plan into an in-memory buffer and reloads it in order to simulate the effect of the two-step workflow.
2018-01-17 17:27:17 -06:00
# do DynamicExpand.
core: Fix TestContext2Apply_provisionerInterpCount This was relying on a no-longer-valid mechanism for accessing the "count" value from a resource block. The original issue this test was written to cover is not really such a sharp edge anymore, since the length is taken from the state during apply rather than from configuration, but it's still a good case to cover.
2018-09-26 13:45:35 -05:00
command = "echo ${length(aws_instance.a)}"
core: interpolate the count config during the apply walk Previously we would interpolate the count config (ResourceConfig.RawCount) only while preparing to dynamic-expand aggregate resource nodes. This is problematic because we do not dynamic-expand any resource nodes during the apply walk, and so previously the count value was not available for interpolation during apply and would result in an error. Now we interpolate RawCount once for each resource we visit during the apply walk -- even though that redundantly interpolates the same config multiple times when count > 1 -- to ensure that it's available by the time we interpolate any remaining expressions in the config and any expressions within "connection" and "provisioner" blocks. This error was masked by us sharing a single RawConfig instance between the plan and apply walks when "terraform apply" is run with no explicit plan file argument, but was exposed by the workflow where the plan is written first to disk since in that case the interpolation result from during the plan phase is not present in the deflated plan object. For this reason, the new context test serializes the plan into an in-memory buffer and reloads it in order to simulate the effect of the two-step workflow.
2018-01-17 17:27:17 -06:00
}
}
Reference in New Issue Copy Permalink