|
1 | 1 | ---
|
2 |
| -page_title: Upgrading to Terraform v1.6 |
3 |
| -description: Upgrading to Terraform v1.6 |
| 2 | +page_title: Upgrading to Terraform v1.7 |
| 3 | +description: Upgrading to Terraform v1.7 |
4 | 4 | ---
|
5 | 5 |
|
6 |
| -# Upgrading to Terraform v1.6 |
| 6 | +# Upgrading to Terraform v1.7 |
7 | 7 |
|
8 | 8 | -> **Tip:** Use the version selector to view the upgrade guides for older Terraform versions.
|
9 | 9 |
|
10 |
| -Terraform v1.6 is a minor release in the stable Terraform v1.0 series. |
| 10 | +Terraform v1.7 is a minor release in the stable Terraform v1.0 series. |
11 | 11 |
|
12 |
| -Terraform v1.6 honors the |
| 12 | +Terraform v1.7 honors the |
13 | 13 | [Terraform v1.0 Compatibility Promises](https://developer.hashicorp.com/terraform/language/v1-compatibility-promises),
|
14 | 14 | but there are some behavior changes outside of those promises that may affect a
|
15 | 15 | small number of users. Specifically, the following updates may require
|
16 | 16 | additional upgrade steps:
|
17 |
| -* [End of experimental period for `terraform test`](#terraform-test) |
18 |
| -* [Deprecated parameters for the S3 backend](#s3-backend) |
| 17 | +* [Validations and checks in the state file](#validations-and-checks) |
| 18 | +* [Deprecated parameters for the S3 backend](#s3-backend) |
19 | 19 |
|
20 | 20 | See [the full changelog](https://github.com/hashicorp/terraform/blob/v1.6/CHANGELOG.md)
|
21 | 21 | for more details. If you encounter any problems during upgrading which are not
|
22 | 22 | covered this guide, please start a new topic in
|
23 | 23 | [the Terraform community forum](https://discuss.hashicorp.com/c/terraform-core)
|
24 | 24 | to discuss it.
|
25 | 25 |
|
26 |
| -## Terraform Test |
| 26 | +## Validations and Checks |
27 | 27 |
|
28 |
| -The previous experimental `terraform test` command has been deprecated and replaced with a fully supported and finalized `terraform test` command. |
| 28 | +Due to a state interoperability issue ([#33770](https://github.com/hashicorp/terraform/issues/33770), [#34014](https://github.com/hashicorp/terraform/issues/34014)) in earlier versions of Terraform, state files created by the Terraform v1.7.x series may not be compatible with the following Terraform versions: |
29 | 29 |
|
30 |
| -There are substantial differences between the previous experimental approach and the finalized approach: |
| 30 | +* Terraform v1.3.0 through v1.3.9 |
| 31 | +* Terraform v1.4.0 through v1.4.6 |
| 32 | +* Terraform v1.5.0 through v1.5.6 |
31 | 33 |
|
32 |
| -- The builtin test provider, `terraform.io/builtin/test`, has been removed and a dedicated syntax introduced for testing files. |
33 |
| -- A new `.tftest.hcl` file extension has been introduced for testing files, allowing a change into the directory structure and test file layout. |
34 |
| -- Test assertions and conditions execute with extended scope and access to the configuration under test. |
| 34 | +If your v1.7.x state file contains `check` blocks or input validations, it will not be compatible with the above versions. Attempting to load a state file created by Terraform v1.7.x in one of the above versions will result in an error similar to `Error refreshing state: unsupported checkable object "var"`. This will particularly affect configurations using the `terraform_remote_state` data source to load state files created by the `v1.7.x` series. |
35 | 35 |
|
36 |
| -The major differences are discussed here, for more information consult the [CLI](/terraform/cli/test) and [Language](/terraform/language/tests) documentation. |
| 36 | +To prevent this issue, users should upgrade any usage of the affected versions to the following patch releases in the relevant minor release series before attempting to process state files created by Terraform v1.7.x: |
37 | 37 |
|
38 |
| -### Directory structure |
| 38 | +* Terraform v1.3.x series users should upgrade to v1.3.10 |
| 39 | +* Terraform v1.4.x series users should upgrade to v1.4.7 |
| 40 | +* Terraform v1.5.x series users should upgrade to v1.5.7 |
39 | 41 |
|
40 |
| -Previously, test files would be placed within their own subdirectories underneath the `tests` directory from the configuration directory. The following example contains three test files using the experimental framework: |
41 |
| - |
42 |
| -``` |
43 |
| -main.tf |
44 |
| -outputs.tf |
45 |
| -providers.tf |
46 |
| -variables.tf |
47 |
| -tests/ |
48 |
| - defaults/ |
49 |
| - test_defaults.tf |
50 |
| - maximums/ |
51 |
| - test_maximums.tf |
52 |
| - minimums/ |
53 |
| - test_minimums.tf |
54 |
| -``` |
55 |
| - |
56 |
| -With the new directory structure, tests are defined using the new `.tftest.hcl` file extension and do not need to be embedded within subdirectories. To help with organization, test files can, optionally, be embedded within a test directory. The name for this test directory defaults to `tests`, but can be overridden with the `-test-directory` flag. |
57 |
| - |
58 |
| -The following examples are both valid directory structures for test files in the updated framework: |
59 |
| - |
60 |
| -``` |
61 |
| -main.tf |
62 |
| -outputs.tf |
63 |
| -providers.tf |
64 |
| -variables.tf |
65 |
| -defaults.tftest.hcl |
66 |
| -maximums.tftest.hcl |
67 |
| -minimums.tftest.hcl |
68 |
| -``` |
69 |
| - |
70 |
| -``` |
71 |
| -main.tf |
72 |
| -outputs.tf |
73 |
| -providers.tf |
74 |
| -variables.tf |
75 |
| -tests/ |
76 |
| - defaults.tftest.hcl |
77 |
| - maximums.tftest.hcl |
78 |
| - minimums.tftest.hcl |
79 |
| -``` |
80 |
| - |
81 |
| -### Test structure and assertions |
82 |
| - |
83 |
| -Previously, a test file would contain a module call and a collection of resources from the builtin `test` provider: |
84 |
| - |
85 |
| -```hcl |
86 |
| -# tests/defaults/test_defaults.tf |
87 |
| -
|
88 |
| -terraform{ |
89 |
| - required_providers { |
90 |
| - test = { |
91 |
| - source = "terraform.io/builtin/test" |
92 |
| - } |
93 |
| - } |
94 |
| -} |
95 |
| -
|
96 |
| -module "main" { |
97 |
| - source = "../.." |
98 |
| -} |
99 |
| -
|
100 |
| -resource "test_assertions" "api_url" { |
101 |
| - component = "api_url" |
102 |
| -
|
103 |
| - equal "scheme" { |
104 |
| - description = "default scheme is https" |
105 |
| - got = module.main.scheme |
106 |
| - want = "https" |
107 |
| - } |
108 |
| - check "port_number" { |
109 |
| - description = "default port number is 8080" |
110 |
| - condition = can(regex(":8080$", module.main.authority)) |
111 |
| - } |
112 |
| -} |
113 |
| -``` |
114 |
| - |
115 |
| -With the new framework each test file is made up of a series of `run` blocks. Each `run` block represents a single `terraform plan` or a `terraform apply` operation executed against the main configuration. Assertions from within these `run` blocks can access outputs, variables, resources, and local values from the main configuration directly. |
116 |
| - |
117 |
| -```hcl |
118 |
| -# tests/defaults.tftest.hcl |
119 |
| -
|
120 |
| -run "test_defaults" { |
121 |
| - assert { |
122 |
| - condition = output.scheme == "https" |
123 |
| - error_message = "default scheme should be https" |
124 |
| - } |
125 |
| -
|
126 |
| - assert { |
127 |
| - condition = can(regex(":8080", output.authority)) |
128 |
| - error_message = "default port number should be 8080" |
129 |
| - } |
130 |
| -} |
131 |
| -``` |
132 |
| - |
133 |
| -The above examples demonstrates the differences in layout, scope and access between the two approaches. In the experimental framework, access is granted as if the configuration was being called like a normal module call. In the released framework, assertions execute as if they are custom conditions defined within the main configuration directly. |
134 |
| - |
135 |
| -The `run` block also applies or plans the main configuration by default, there is no need for the specific module call seen in the experimental framework. |
| 42 | +Terraform versions prior to v1.3.0 and equal to or after v1.6.0 are not affected by this issue. |
136 | 43 |
|
137 | 44 | ## S3 Backend
|
138 | 45 |
|
|
0 commit comments