v0.21+: Pessimistic operator ~> for Terraform version detection not working as expected

[Roberdvs]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

---

Overview of the Issue

Atlantis 0.21 introduced a feature to autodetect the Terraform version based on version constraints since it previously only did when an exact version was specified.

Based on my experience, this isn't working as someone familiar with Terraform version constraints for providers and modules would expect.

When specifying version ~> 1.0 for modules and providers, Terraform uses the latest minor version of the 1.x major. Meanwhile, when specifying required_version ~> 1.0 for Terraform core versions, Atlantis is using the lowest version amongst the ones it has installed, i.e: 1.0.11.

Furthermore, with this same version constraint in v0.20, Atlantis was using the default Terraform version (Terraform 1.3) so this might even be considered a regression when upgrading to 0.21. Now, even when specifying a default TF version in Atlantis server, it's still picking 1.0.11.

In summary, I would expect required_version ~> 1.0 to pick the latest available minor version, either from the ones Atlantis has locally installed or by detecting the latest one available to download, which mirrors Terraform behaviour for modules and providers.

Reproduction Steps

Create a project with the following Terraform version constraint:

terraform {
  required_version = "~> 1.0"
}

Expected behaviour. Atlantis uses the latest minor version available at the time.

Actual behaviour. Atlantis is using version 1.0.11

As a workaround specifying required_version ~> 1.3 makes Atlantis use Terraform 1.3.5.

Logs

Environment details

Atlantis 0.21.0
ATLANTIS_DEFAULT_TF_VERSION : v1.3.5

Let me know if there's more information I can provide to help with troubleshooting and thank you very much for the effort put behind this project ❤️

[nitrocode]

The ~> operator should pin the last number you mention

terraform {
  # results in 1.x pin
  required_version = "~> 1.0"
}

terraform {
  # results in 1.0.x pin
  required_version = "~> 1.0.0"
}

But youre saying that this results

terraform {
  # results in 1.0.x pin instead of 1.x pin as mentioned by the tf docs
  required_version = "~> 1.0"
}

But if that isn't working as expected then perhaps try ~> 1 for now as a stop-gap?

If that doesn't work, then perhaps it's an issue in the library we're using? If so, then the best way to raise the issue is in the librarary's issues page.

atlantis/go.mod

Line 42 in 585ce1e

github.com/warrensbox/terraform-switcher v0.1.1-0.20221027055942-201c8e92e997

The original PR is #1776 from @fblgit (in case you know the answer here).

[Roberdvs]

Forgot to link the actual Terraform documentation about the pessimistic operator.

In reality Atlantis is complying properly, version 1.0.11 is valid for a ~> 1.0 constraint.

The issue is more related to the difference in behaviour between Terraform and Atlantis.

When you do a terraform init on a fresh project (without .terraform.lock.hcl), Terraform downloads the newest versions of providers and modules that comply with the given constraint , meanwhile Atlantis is picking the lowest Terraform core version. I would have expected Atlantis to follow Terraform's behaviour (and at least choose the most recent one from the ones it has available locally since I assume autodetecting Terraform releases to download is more of a hassle), but if this is working as intended feel free to close the issue.

But if that isn't working as expected then perhaps try ~> 1?

This is not ideal because you'd be saying that your Terraform code is compatible with Terraform v2, which is not an issue at the moment but could be if an eventual v2 release happens.

[nitrocode]

From the link to the pessimistic operator you provided

~>: Allows only the rightmost version component to increment. For example, to allow new patch releases within a specific minor release, use the full version number: ~> 1.0.4 will allow installation of 1.0.5 and 1.0.10 but not 1.1.0. This is usually called the pessimistic constraint operator.

So it sounds like an issue with our 3rd party library?

We're using the latest oct 27 2022 release https://github.com/warrensbox/terraform-switcher/releases/tag/0.13.1300

[nitrocode]

Related issues

• ~> 1.0 should give me the same version as >= 1.0.0, < 2.0.0 does warrensbox/terraform-switcher#226
• tfswitch doesn't interpret the pessimistic constraint operator the same way that Terraform interprets it warrensbox/terraform-switcher#215

Seems like it was fixed in 0.13.1218 and we're using 0.13.1300 so perhaps there was a regression?

Those issues are closed but it's worth reopening or commenting.

@Roberdvs could you follow up with them?