Terraform gains upgrades for module tests, explorer, and more

The latest Terraform Cloud and Enterprise enhancements help users leverage high-quality modules, monitor their workspace health, minimize management overhead, and more.

The HashiCorp Terraform team has made a lot of progress over the past few months, simplifying IT operations, increasing developer velocity, and cutting costs for organizations. The new Terraform Cloud and Terraform Enterprise improvements — all now generally available — include:

  • Test-integrated module publishing
  • Explorer for workspace visibility
  • Inactivity-based destruction for ephemeral workspaces
  • Priority variable sets
  • Resource replacement from the UI
  • Auto-apply for run triggers
  • Version constraints in the Terraform version selector

»Test-integrated module publishing

Back in October 2023 at HashiConf, we released the beta version of test-integrated module publishing for Terraform Cloud, along with the Terraform test framework, to streamline module testing and publishing workflows. Now we are excited to announce general availability of test-integrated module publishing. This new feature helps module authors and platform teams produce high-quality modules quickly and securely with more control over when and how modules are published.

Test results are displayed in the Terraform Cloud private registry

Test results are displayed in the Terraform Cloud private registry

Since the beta launch, we have made several improvements.

First, branch-based publishing and test integration are now compatible with all supported VCS providers in Terraform Cloud: GitHub, GitLab, Bitbucket, and Azure DevOps. Also, test results are now reported back to the connected repository as a VCS status check when tests are initiated by a pull request or merge. This gives module developers immediate in-context feedback without leaving the VCS interface.

Finally, to support customers publishing modules at scale, both the Terraform Cloud API and the provider for Terraform Cloud and Enterprise now support branch-based publishing and enablement for test-integrated modules in addition to the UI-based publishing method.

An example of a test result posted back to a GitHub pull request

An example of a test result posted back to a GitHub pull request

Along with being GA in Terraform Cloud, test-integrated module publishing is also available in the January 2024 (v202401-1) release of Terraform Enterprise, available now.

»Explorer for workspace visibility

After we announced the beta version of the explorer for workspace visibility back at HashiDays in May 2023, we have been receiving lots of feedback and making improvements. We are now excited to announce general availability of the explorer for workspace visibility to help users ensure that their environments are secure, reliable, and compliant.

Since the beta launch, we’ve made enhancements to allow users to find, view, and use their important operational data from Terraform Cloud more effectively as they monitor workspace efficiency, health, and compliance. For example, we improved the query speed, added more workspace data, introduced CSV exports, and provided options for filtering and conditions. Popular uses of explorer include tracking Terraform module and provider usage in workspaces, finding workspaces without a connected VCS repo, and identifying health issues like drifted workspaces and continuous validation failures. With the new public Explorer API, users can automate the integration of their data into visibility and reporting workflows outside of Terraform Cloud.

Explorer conditions: organization workspaces filtered by project name and run status

Explorer conditions: organization workspaces filtered by project name and run status

»Inactivity-based destruction for ephemeral workspaces

Developer environments cost money to set up and run. If they are left running after developers have finished using them, your organization is incurring unnecessary costs. Ephemeral workspaces in Terraform Cloud and Enterprise— workspaces that expire after a set time and automatically de-provision — are a way to solve this cost overrun. However, it is sometimes hard to predict how much time you should give an ephemeral workspace to live.

To give users a more dynamic mechanism for ephemeral workspace removal, we’ve introduced inactivity-based destruction for ephemeral workspaces in Terraform Cloud Plus and Terraform Enterprise (v202312-1). Users of those products can now set a workspace to "destroy if inactive", allowing administrators and developers to establish automated clean up of workspaces that haven't been updated or altered within a specified time frame. This eliminates the need for manual clean-up, reducing wasted infrastructure costs and streamlining workspace management.

Example: This workspace will be set to auto-destroy seven days after its last apply.

Example: This workspace will be set to auto-destroy seven days after its last apply.

»Priority variable sets to enforce variables across workspaces

Variable sets allow Terraform Cloud users to reuse both Terraform-defined and environment variables across certain workspaces or an entire organization. One of the core use cases for this feature is credential management, but variables can also manage anything that can be defined as Terraform variables. When using variable sets for credential management, it is critical to ensure that these variables cannot be tampered with by end users.

Priority variable sets for Terraform Cloud and Terraform Enterprise (v202401-1) provide a convenient way to prevent the over-writing of more infrastructure-critical variable sets, such as those used for credentials. Once the platform team has prioritized a variable set, even if a user has access to workspace variables or can modify a workspace’s Terraform configuration, they still won’t be able to override variables in that prioritized set.

Enable variable set priority to enforce variable values

Enable variable set priority to enforce variable values

When creating a new variable set, check the "Prioritize the variable values in this variable set" box to make it a priority variable set.

»Resource replacement from the UI

In the past, Terraform Cloud users were not able to use the UI to regenerate a damaged or degraded resource (or resources) for a VCS-connected workspace without switching to the CLI workflow. This was a tedious and error-prone manual process.

In some cases, a remote object may become damaged or degraded in a way that Terraform cannot automatically detect. For example, if software running inside a virtual machine crashes but the virtual machine itself is still running, Terraform will typically have no way to detect and respond to the problem because Terraform directly manages the machine as a whole.

Now, if you know that an object is damaged or if you want to force Terraform to replace it for any other reason, you can override Terraform's default behavior using the replace resources option to instruct Terraform to replace the resource(s) you select. Users can now create a new run via the Terraform Cloud UI with the option to replace resources in addition to the CLI and API approach. The replacement workflow is also available in v202401-1 of Terraform Enterprise.

Replace resources by selecting them in the “Start a new run” dialog

Replace resources by selecting them in the “Start a new run” dialog

»Auto-apply for run triggers

Run triggers let users connect two workspaces in Terraform Cloud to automatically queue runs when the parent workspace is successfully applied. This is commonly used in multi-tier infrastructure deployments where resources are split between multiple workspaces, or with shared infrastructure like networking or databases. In the past, runs initiated by a run trigger did not auto-apply. Instead, users had to manually confirm the pending run in each workspace individually.

The new “auto-apply run triggers” option in the workspace settings allows workspace admins to choose whether to auto-approve runs initiated by a run trigger. This setting is independent from the workspace auto-apply setting, providing more flexibility in defining workspace behavior. It provides an automated way to chain applies across workspaces to simplify operations without human intervention.

Auto-apply run triggers are now generally available in Terraform Cloud and Terraform Enterprise v202401-1.

»Version constraints in the Terraform version selector

Each workspace in Terraform Cloud defines the version of Terraform used to execute runs. Previously, version constraints could be set via the workspaces API, but in the UI version selector, the choices were limited to specific versions of Terraform or the “latest” option, which always selects the newest version. Users had to either manually update versions for each workspace or accept the risk of potential behavior changes in new versions.

Terraform Cloud now has an updated Terraform version selector that includes version constraints, allowing workspaces to automatically update specific Terraform versions with patch releases while staying within the selected major or minor version. This provides a more seamless and flexible experience for users who rely on the web console and don’t have direct API access. This feature is also coming soon to Terraform Enterprise (expected in v202402-1).

New version constraint selections allow a workspace to auto-update Terraform patch releases within a minor version.

New version constraint selections allow a workspace to auto-update Terraform patch releases within a minor version.

»Get started with Terraform Cloud

These Terraform Cloud and Enterprise enhancements represent a continued evolution aimed at helping customers maximize their infrastructure investments and accelerate application delivery.

To learn more about these features, visit our Terraform guides and documentation on HashiCorp Developer. If you are new to Terraform, sign up for Terraform Cloud and get started for free today.


Sign up for the latest HashiCorp news

By submitting this form, you acknowledge and agree that HashiCorp will process your personal information in accordance with the Privacy Policy.