anyone encountered issues running plan in atlantis after the

Question

anyone encountered issues running plan in atlantis after the new 1 4 terraform release We didn t commit Terraform lock files to our repo and apparently that the latest version broke the behavior of the plugin cache esp if you didn t commit Terraform lock files What happens here I think is because we use local directory as plugin cache when multiple init is running at the same time and trying to access the plugin cache it lead to this error `text file busy` Error when running plan ```Initializing the backend Initializing provider plugins <http terraform io builtin terraform|terraform io builtin terraform> is built in to Terraform Finding latest version of hashicorp template Finding hashicorp aws versions matching ~ gt 4 0 Installing hashicorp template v2 2 0 Installed hashicorp template v2 2 0 signed by HashiCorp Installing hashicorp aws v4 58 0 Error Failed to install provider Error while installing hashicorp aws v4 58 0 open atlantis data plugin cache registry terraform io hashicorp aws 4 58 0 linux amd64 terraform provider aws v4 58 0 x5 text file busy```

Aiman Ismail · Answer

side question is it possible to override the Terraform CLI version globally from the server side I want to revert our CLI revert from using 1 4 at least for now I know we can set the default CLI version on server side but it is lower precedence than the `required version` config in the folder I know I can set the `terraform version` in `atlantis yaml` but that is only per project There are no way AFAIK that we can override TF version centrally

PePe Amengual · Answer

you can pass a tf env var to keep the old behaviour

PePe Amengual · Answer

nop I m lying

Aiman Ismail · Answer

yeah I found `TF PLUGIN CACHE MAY BREAK DEPENDENCY LOCK FILE` and set that in Helm That fixed the issue but I had to `rm rf atlantis data plugin cache` first before it works properly again

PePe Amengual · Answer

Aiman Ismail · Answer

With this new breaking change from Terraform CLI is it currently recommended to commit the Terraform lock file to git I think I read somewhere before that I shouldn t commit it when using Atlantis but I might ve remembered wrong

wby · Answer

Hashicorp recommends it strongly

wby · Answer

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

wby · Answer

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 gt 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

wby · Answer

< 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

wby · Answer

```ATLANTIS DEFAULT TF VERSION 1 3 9 ```

wby · Answer

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

Aiman Ismail · Answer

I think I ve misunderstood the `required version` config before We have it set in all our repos to ` gt = 1 0` which is the reason why it always updates to the latest one This also made it hard for us to globally override it Will be removing `required version` from all our Terraform files in the future unless only when we need to specifically use a Terraform version for that folder

wby · Answer

I think it is a good practice if not required for sure tools like `tflint` will complain if you don t have it set I would suggest setting it but just setting it either to an exact version or to a range that makes sense for you

wby · Answer

like you could do `~ gt 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