nop I'm lying

I don’t do it (I’m the one who made the request for them to add a method to configure the new config option via env var). There have been a lot of contentious threads about Hashicorp not supporting not using a lockfile, as well as some of the deficiencies with the current lockfile implementation.

They made it very clear in the discussions around that workaround for 1.4 that this workaround may not be continued / followed in future Terraform versions.

Terraform automatically creates or updates the dependency lock file each time you run the terraform init command. You should include this file in your version control repository so that you can discuss potential changes to your external dependencies via code review

https://developer.hashicorp.com/terraform/language/files/dependency-lock We don’t use it, because we pin almost all of our providers / modules to exact versions, and because we use Renovate to update our dependencies (it still doesn’t manage the lockfile as well as you might like). That said, I have never heard of any Atlantis specific reason that you shouldn’t check in the lockfile; you probably should check it in unless you have a good reason not to.

@Aiman Ismail you can set the default Terraform version as you mentioned, though Atlantis will still try to get another version if it’s requested in the version constraints

But if you have

required_version: 1.4

in the config, that will always be a problem; presumably you could resolve that by reverting the code change that updated the required version, unless I’m misunderstanding your question?

like you could do

~> 1.3.0

or something. We use Renovate to manage all the deps, and just pin to exact version for both provider / module versions, and the terraform required versions, but it does create some extra noise / work to do it that way.