Terraform 1.2 Improves Exception Handling and Updates to the CLI-driven Workflow
Now generally available, HashiCorp Terraform 1.2 introduces exception handling with pre- and post-conditions, support for non-interactive Terraform Cloud operations in a CI/CD pipeline, and CLI support for Run Tasks.
We’re excited to announce the release of HashiCorp Terraform 1.2, now immediately available for download as well as for use in HashiCorp Terraform Cloud. Terraform is widely adopted as the standard for multi-cloud provisioning and automation for individuals and teams at any scale. This release introduces new ways to raise errors and validate dynamic module inputs, along with usability improvements for the cloud integration with CI/CD pipelines, and support for Terraform Cloud run tasks.
» Exception Handling with Preconditions and Postconditions
Many Terraform practitioners are in charge of writing Terraform modules that are consumed by other application developer teams, all with varying levels of Terraform experience. Throughout our interactions with the community and our customers, we’ve seen a common pain point for many module authors — a need for better ways to let end-users know early on if inputs are valid and work as intended.
Prior to this release, Terraform’s primary answer to this need was to use custom variable validation, which runs a certain level of validation over input variables to check if they match what’s expected. However, there were many complex scenarios that variable validation couldn’t solve, largely because variable validation couldn’t account for dynamic data that the validation phase could not see.
In order to provide better validation for dynamic module inputs, Terraform 1.2 introduces precondition and postcondition blocks, allowing Terraform practitioners to capture assumptions in configuration and raise errors earlier and in context. These condition blocks can be written in configuration and can apply to resources, data sources, and outputs. They are especially useful for module authors, who can set up helpful error messages to ensure that conditions are met before an apply
can take place, providing a clean contract for modules.
Preconditions and postconditions are not only valuable for validating module inputs, but also for defining apply-time checks for correctness. If values are not known until apply-time, Terraform will do another check at the apply phase to ensure that conditions are met. If they aren’t met, the apply
will halt and provide relevant context on how to resolve the issue. Additionally, preconditions and postconditions create a more precise software contract for modules, making configuration more maintainable and extensible over time.
Learn how to use preconditions and postconditions with our Validate Modules with Custom Conditions tutorial on HashiCorp Learn.
» Non-Interactive Terraform Cloud CI Operations
The cloud integration was added as part of the Terraform 1.1 release. This new way to interact with Terraform Cloud through the CLI has been met with rave reviews. However, there were some limitations to existing CI/CD workflows. Therefore, this release of Terraform has added two new environment variables and updated support for an existing environment variable.
The first new variable is TF_CLOUD_ORGANIZATION
, which can be used to configure the desired organization the workspace should operate within.
The second new variable is TF_CLOUD_HOSTNAME
, which can be used to configure an alternative hostname for the cloud integration to interact with. This is especially important for Terraform Enterprise environments.
Lastly, the TF_WORKSPACE
variable has been updated to include support for the cloud integration's attribute for workspaces.
These new variables allow you to configure the cloud integration as an empty block inside the Terraform block. Then, during Terraform operations, the environment variables will be referenced more dynamically and flexibly.
Follow the HashiCorp Learn tutorial to review how to use environment variables to configure your Terraform Cloud integration within a CircleCI build pipeline.
» Run Tasks CLI Support
Terraform Cloud Run Tasks enhance your Terraform Cloud workflow to include third-party tools. The integrations can include options such as vulnerability scanners, cost management, code scanning, and more. The release of Terraform 1.2 adds support for Run Tasks, which just became generally available. A terraform apply
operation now provides the output from a workspace’s configured run tasks directly in the CLI-based output. This enables you to have immediate access to the full context of your Terraform workflow.
Learn how to configure and use Terraform Cloud run tasks in your infrastructure provisioning workflow by following the Snyk Run Task tutorial on HashiCorp Learn.
» Getting Started with Terraform 1.2
- Download the Terraform 1.2 release
- Sign up for a free Terraform Cloud account
- Review the preconditions and postconditions documentation.
- Explore our HashiCorp Learn tutorials, including the Validate Modules with Custom Conditions, Deploy Infrastructure using Terraform Cloud and CircleCI, and Snyk Run Task tutorials.
For more details, please see the full HashiCorp Terraform 1.2 changelog. This release wouldn't have been possible without all of the great community feedback we've received via GitHub issues, as well as continued feedback from our customers. Thank you!
Sign up for the latest HashiCorp news
More blog posts like this one
Fix the developers vs. security conflict by shifting further left
Resolve the friction between dev and security teams with platform-led workflows that make cloud security seamless and scalable.
HashiCorp at AWS re:Invent: Your blueprint to cloud success
If you’re attending AWS re:Invent in Las Vegas, Dec. 2 - Dec. 6th, visit us for breakout sessions, expert talks, and product demos to learn how to take a unified approach to Infrastructure and Security Lifecycle Management.
Speed up app delivery with automated cancellation of plan-only Terraform runs
Automatic cancellation of plan-only runs allows customers to easily cancel any unfinished runs for outdated commits to speed up application delivery.