-
Notifications
You must be signed in to change notification settings - Fork 9.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
terraform: Fix required version constraint diags #25898
Conversation
If a module has multiple terraform.required_version constraints, any failures would point at the last constraint in the error diagnostics. If an earlier constraint was the actual problem, this leads to confusing errors like this: Error: Unsupported Terraform Core version on main.tf line 6, in terraform: 6: required_version = ">= 0.13.0" This configuration does not support Terraform version 0.13.0. The error was due to storing the declaration range of the constraint as a pointer to the contents of a loop variable, which was later overwritten in later iterations of the loop. Instead we now use HCL's handy Ptr() method to create a direct pointer to the range struct.
Codecov Report
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh! Great catch/fix with that .Ptr()
!
This is a somewhat new situation, so I have some thoughts about the error message and I'm curious what you think.
Including multiple "required_version" settings in a single module used to result in an error (with the exception of an override file); I think I'd expect a different error that the one shown here when there are multiple required_versions
and terraform cannot chose a single version from those constraints, similar to the provider error (this is not the "real" error, but close):
This version of Terraform does not meet the constraints "~> 0.9.0, >= 0.13.0"
(possibly including locations for both constraints)
Thanks for the comment! I think about what we're doing here differently than the provider installer case of choosing a version from the given constraints. Here we already have a single version (the current one), and we're verifying that it satisfies each constraint in turn. If I had a configuration with multiple It would be nice to be able to require at most one Terraform version constraint (aside from overrides), but I think that would be a breaking change, so we can't do it until 0.14 at the earliest. |
That sounds reasonable to me! I am sorry, I had meant to approve this as-is and not block you on that question. Thank you! |
Oh, this exact brand of bug is the main reason why that |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
If a module has multiple
terraform.required_version
constraints, any failures would point at the last constraint in the error diagnostics. If an earlier constraint was the actual problem, this leads to confusing errors like this:The error was due to storing the declaration range of the constraint as a pointer to the contents of a loop variable, which was later overwritten in later iterations of the loop. Instead we now use HCL's handy
Range.Ptr
method to create a direct pointer to the range struct.Fixes #25833