What Is New in Terraform 1.4
Terraform 1.4 is a minor release packed with enhancements for the core configuration language and the overall user experience. It introduces a new function for testing, refines how you manage sensitive values, and includes numerous improvements to provider operations.
| Category | Key Changes |
|---|---|
| New Features | New strcontains function, terraform test command, optional sensitive attribute for variable validation blocks. |
| Enhancements | Improved error messages for dynamic blocks, new -allow-missing flag for terraform state rm, and continued progress on the config-driven remove workflow. |
| Provider & CLI | More robust provider installation, clearer messaging when using community providers, and a new -json output option for terraform version. |
| Bug Fixes | Fixes for expression evaluation, ignore_changes behavior, and the handling of unknown values in various functions. |
What new functions were added in Terraform 1.4?
The main addition is the strcontains function. This function checks if one string contains another substring, returning a boolean value. It fills a common gap in the string manipulation toolkit.
In practice, this simplifies conditionals where you need to check for the presence of specific text within a larger string, something that previously required more complex workarounds.
# Example using the new strcontains function
contains_hello = strcontains("hello world", "hello") # Returns true
How does Terraform 1.4 improve handling sensitive data?
This release makes variable validation blocks more flexible by allowing the sensitive attribute to be optional. When set to true, it prevents the validation error message from revealing the sensitive value in the UI.
This matters because it prevents accidental exposure of secrets like passwords or API keys in plan or apply output if a variable validation rule fails, which is a common concern when working with pipelines.
variable "api_key" {
type = string
sensitive = true
validation {
condition = length(var.api_key) > 16
error_message = "The api_key value is not valid." # This won't show the value
}
}
What CLI improvements should I know about?
The terraform state rm command now has an -allow-missing flag. This allows the command to succeed even if the specified resource instance doesn't exist in the state, making it safer for use in automation scripts.
Furthermore, the terraform version command now supports a -json output flag. This provides machine-readable output, which is much easier to parse for tools that need to check Terraform's version.
Other Notable CLI Updates
- Continued enhancements to the config-driven remove workflow, moving it closer to full stability.
- Improved error messages for invalid
dynamicblocks, helping you pinpoint configuration issues faster.
Were there any changes to provider installation?
Yes, the process for installing providers from the Terraform Registry has been made more robust. The underlying mechanics have been improved to handle network interactions more reliably.
You'll also see clearer messaging when using community providers, making it more obvious that you're relying on providers from namespaces other than hashicorp. This helps with transparency and auditability of your codebase.
FAQ
Is the terraform test command now stable?
No, the terraform test command is mentioned in the changelog but is still considered an experimental feature. You must enable it explicitly with an environment variable as it is not yet enabled by default for general use.
Does the new strcontains function work with collections?
No, the strcontains function is specifically for checking substrings within strings. To check if a list contains a value, you continue to use the existing contains function.
What happens if I use terraform state rm -allow-missing on a resource that exists?
The behavior is unchanged from the standard state rm command. The resource will be removed from the state file as expected. The -allow-missing flag only suppresses the error if the resource address cannot be found.
Are there any breaking changes in Terraform 1.4?
Terraform 1.4 is a minor release and aims to be backward-compatible. The changelog does not highlight any breaking changes to the core language or workflows that would affect most users upgrading from v1.3.
Why would I use the JSON output for terraform version?
The new -json flag is designed for machine parsing. It's useful for automation scripts, CI/CD pipelines, or monitoring tools that need to programmatically verify the exact version of Terraform and its plugins without parsing human-readable text.