Allow additional specifiers in terraform's required_version other than = e.g. ~> and >

[llamahunter]

Currently, it appears that the code in project_command_builder.go only accepts terraform.required_version specifications that exactly specify a single version, rather than a range or other version constraint. Seems odd to have this limited behavior, as atlantis is built to support a wide range of terraform versions. It seems that the version constraints should be interpreted and the latest matching terraform version selected.

Also, the silent failure of the current approach is misleading.

[llamahunter]

Is there a reason why this was not implemented? Looking at the code, it seems reasonably straightforward to do so. Just need to get the list of all available terraform versions, which can be pulled from https://api.github.com/repos/hashicorp/terraform/tags

[llamahunter]

Or, slightly more hackily, could parse the HTML returned from ${TFDownloadURL}/terraform to get all the version numbers. But, that presumes that whatever URL is configured works similar to https://releases.hashicorp.com/terraform and provides a link tree.

[lkysow]

I think this was likely not implemented because it makes the behaviour non-deterministic or because it was too difficult. I didn't implement it though so I can't say for sure :)

[grimm26]

@llamahunter so you would want atlantis to download all terraform versions that match your non-exact constraint? It can't use that info to set a default version to use, though.

[llamahunter]

I would want it to download the most recently available version that matches the version constraint.

[scruplelesswizard]

Per the semver spec (which Terraform follows), the version with the greatest precedence shall be selected.

If a user wants to use a specific version of Terraform they can indicate that by using a = constraint.

The Terraform documentation specifically covers the Version Constraint Syntax and Version Constraint Behavior

[jlestrada]

Any update on this request? It seems odd that this is considered a feature as opposed to a bug since it is ignoring the version constraint syntax that is supported by terraform. We have had to modify our version constraint from what we do with local development work to fit the needs of atlantis (to be explicit in version number).

Happy to help contribute as well if this is agreed to be something that can be supported! Seems like a number of members are facing similar issues.

Ah my mistake, looks like this PR is in review but just taking some time to get out the door. I just need to be patient 😄

[scruplelesswizard]

@jlestrada Feel free to give the PR a review if you have the cycles. I'm sure that would help it land more quickly

[mcaulifn]

Will #1266 also read from .terraform-version?

[scruplelesswizard]

@mcaulifn It uses the Terraform code to do the ingest and interpretation of versions, so the behaviour will be identical to that of Terraform

[llamahunter]

what's the status of this? The PR that was purportedly going to fix this (#1266) was abandoned.

[nitrocode]

It seems that PR #1266 was abandoned @llamahunter and the branch was also deleted very recently.

FWIW, in recent versions of terraform such as 0.15.x and 1.x, we do not have to worry so much about tfstate since the tfstate is backwards compatible. For terraform root modules that have been upgraded to 1.x, I use the default atlantis version which is the latest terraform version and I use a required_version = "> 1.0" and it just works.

I'd be in favor of another PR (or the same PR if the branch was undeleted and rebased) that would allow more than just required_version = "=1.3.5" such as ~> expressions.

One downside of this proposed change is that if you were to set the constraint to ~> 1.3 it would download 1.3.5 today and then as new versions came out, it would also download 1.3.6, 1.3.7, etc until 1.4.x was released. Each binary is about 80 MB and could fill up your volume.

If the change to support > and ~> is added, perhaps it should also remove older versions (if they haven't been accessed in awhile) but that may be tricky to do if you have a mixture of = x.x.x and ~> x.x.x. On second thought, if the above proposed feature (not the stale tf removal) was implemented then perhaps removing the stale binaries should be the responsibility of the developer using atlantis.