I ran into the following issue:
running "/atlantis/data/bin/terraform0.14.6 init -input=false -no-color -upgrade" in "/atlantis/data/repos/tunein/atlantis/16/default/deploy/environments/production": exit status 1
Initializing the backend...
Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.
Initializing provider plugins...
- Finding hashicorp/aws versions matching "3.28.0"...
- Using hashicorp/aws v3.28.0 from the shared cache directory
Error: Failed to install provider from shared cache
Error while importing hashicorp/aws v3.28.0 from the shared cache directory:
the provider cache at .terraform/providers has a copy of
registry.terraform.io/hashicorp/aws 3.28.0 that doesn't match any of the
checksums recorded in the dependency lock file.
and after looking up the error (https://www.terraform.io/docs/cli/commands/providers/lock.html)
I think that -upgrade is the problem here, but I can't be sure.
changing the workflow to look like this:
+ "workflows": {
+ "default": {
+ "apply": {
+ "steps": [
+ "apply"
+ ]
+ },
+ "plan": {
+ "steps": [
+ {
+ "run": "terraform init -input=false -no-color"
+ },
+ "plan"
+ ]
+ }
+ },
I now get this:
exit status 1: running "terraform init -input=false -no-color" in "/atlantis/data/repos/tunein/atlantis/16/default/deploy/environments/production":
Error: Unsupported Terraform Core version
on main.tf line 15, in terraform:
15: required_version = "0.14.6"
This configuration does not support Terraform version 0.13.0. To proceed,
either choose another supported Terraform version or update this version
constraint. Version constraints are normally set for good reason, so updating
the constraint may lead to other errors or unexpected behavior.
despite having my .atlantis.yaml set as:
projects:
- name: production
dir: ./deploy/environments/production
terraform_version: 0.14.6
and main.tf with:
terraform {
...
required_providers {
aws = {
source = "hashicorp/aws"
version = "3.28.0"
}
}
required_version = "0.14.6"
}
I was able to fix the version issue by changing the workflow to terraform${ATLANTIS_TERRAFORM_VERSION} init -input=false -no-color. I think this needs to be better called out in the documentation, right now, it makes it seem that simply using terraform in a custom workflow will do the right thing, but it won't.
if you use extra-args it'll use the version you specify in your atlantis.yaml.
referencing the binary directly in a custom run command doesn't work if you're using the non-default. We can make this clearer in our docs.
+1 on this issue as we encountered it with Terraform v0.14. Seems like the two workaround are:
.terraform.lock.hcl file to repo. This will cause atlantis to always pull down the latest version of providers during initextra_args: ["-upgrade", "false"] to the init step. This will cause atlantis to respect the .terraform.lock.hcl file if it exists.I am going with custom workflow method for now..
if you use extra-args it'll use the version you specify in your atlantis.yaml.
referencing the binary directly in a custom run command doesn't work if you're using the non-default. We can make this clearer in our docs.
Are extra args deduplicated? Such that if I specify an argument that is already a default (but with a different value), are they both passed to terraform? Or does last arg win?
Are extra args deduplicated? Such that if I specify an argument that is already a default (but with a different value), are they both passed to terraform? Or does last arg win?
They don't seem to get dedup. Adding extra_args: ["-upgrade", "false"] duplicates the -upgrade flag.
"/atlantis/bin/terraform0.14.7 init -input=false -no-color -upgrade -upgrade=false"
Most helpful comment
They don't seem to get dedup. Adding
extra_args: ["-upgrade", "false"]duplicates the-upgradeflag.