Terraform 1.6 is now generally available, highlighted by a powerful new testing framework to help authors systematically validate the functionality of their code.
Today, we are excited to announce the general availability of HashiCorp Terraform 1.6, which is ready for download and immediately available for use in Terraform Cloud. This release adds numerous features to enhance developer productivity and practitioner workflows, including a powerful new testing framework, improvements to config-driven import, enhancements for Terraform Cloud CLI workflows, and more.
Let’s take a look at what’s new.
Terraform practitioners need to know that their configurations will function as expected. This is especially true for authors publishing reusable modules for their team, organization, or the public community. Over time, HashiCorp has added several testing capabilities to Terraform, including input variable validation, resource preconditions and postconditions, and check blocks. These features provide actionable feedback to module consumers during regular Terraform operations but do not fill the need for more traditional, developer-centric unit and integration testing.
The general availability of Terraform 1.6 brings a new Terraform test framework that deprecates and replaces the previous experimental feature first added in version 0.15. Terraform tests allow authors to consistently validate the functionality of their configuration in a safe environment. Tests are written using familiar HashiCorp Configuration Language (HCL) syntax, so there is no need to learn a new language to get started.
Using a sequence of one or more run
blocks, authors can create a suite of unit and integration tests with custom assertions evaluated against various combinations of input values and provider configurations. For more comprehensive testing, helper modules can be invoked to set up a temporary testing environment or perform advanced validations.
Tests are executed with the terraform test
command, which:
.tftest.hcl
)run
blocksTerraform test is a powerful framework for authors to automate the validation of Terraform configurations and modules, improving the quality and reliability of their code. You can learn more about the framework on the Testing Terraform overview page, refer to the configuration documentation for the full syntax and usage examples, and get hands-on with the Write Terraform tests tutorial.
Terraform 1.5 introduced config-driven import, a new method for importing existing resources into Terraform. Initially, however, the id
attribute in import
blocks supported only static values. In Terraform 1.6, the id
attribute now accepts expressions referring to other values, such as variables or resource attributes. String interpolation is also supported to help build more complex IDs. The examples below show both techniques:
import { # You can now provide the import ID via a variable id = var.bucket_name to = aws_s3_bucket.example} import { # The aws_s3_bucket_versioning resource includes the AWS account in its import ID id = "${var.bucket_name},${data.aws_caller_identity.current.account_id}" to = aws_s3_bucket_versioning.example}
For Terraform Cloud customers using the CLI-driven run workflow, Terraform 1.6 brings two new features. First, the cloud
block now accepts a Terraform Cloud project name. The project will be used when creating new workspaces via the CLI and to filter workspaces returned by the terraform workspace list
command:
terraform { cloud { organization = "my-org" workspaces { project = "networking-development" tags = ["networking", "source:cli"] } }}
Second, Terraform Cloud CLI workflows now have the ability to save cloud plans to be applied later. Saved plans is a new run mode that works with the Terraform 1.6 CLI or the Terraform Cloud API. This mode allows you to:
Saved cloud plans use the same terraform plan -out <file>
syntax as locally executed plans. To preserve the security of sensitive data in the plan file, only a thin reference to the remote run is saved locally. Once a suitable plan has been identified, use terraform apply <file>
to apply it. You can learn more in the Terraform Cloud CLI-driven run workflow documentation.
Terraform 1.6 also brings several significant changes to the configuration format of the Amazon S3 remote state backend. These changes are intended to better align with the AWS SDK and the official Terraform AWS provider. Examples include the relocation of several attributes into nested blocks, support for additional environment variables, and new options to customize the AWS service endpoints. (Note that existing configurations will continue to work as in previous versions, but users may receive warnings about deprecated attributes after upgrading to Terraform 1.6.)
For more details about everything new and changed in Terraform 1.6, please review the full HashiCorp Terraform 1.6 changelog. To get started with HashiCorp Terraform, you can:
As always, the latest Terraform release wouldn't have been possible without the great community feedback received via GitHub issues and from our customers. We are particularly grateful to everyone who provided feedback on the Terraform test framework during the experimental phase. Thank you!
Customers can now deploy Terraform Enterprise using Podman on Red Hat Enterprise Linux. Recent releases also improve VCS, policy, and run task workflows at scale.
Golden patterns for infrastructure and security automation workflows lie at the core of The Infrastructure Cloud. Here’s how to implement them using HashiCorp Cloud Platform services.
Learn about Terraform features that can optimize cloud spending at every stage of growth.