$ terraform version
Terraform v0.13.1
+ provider registry.terraform.io/-/aws v3.4.0
+ provider registry.terraform.io/hashicorp/aws v2.70.0
Terraform file (config.tf):
#=============================#
# AWS Provider Settings #
#=============================#
provider "aws" {
version = "~> 2.69"
region = var.region
profile = var.profile
}
#=============================#
# Backend Config (partial) #
#=============================#
terraform {
required_version = ">= 0.12.28"
backend "s3" {
key = "dev/test/terraform.tfstate"
}
}
Backend config file (/config/backend.config):
#
# Backend Configuration
#
# AWS Profile (required by the backend but also used for other resources)
profile = "my-dev-user"
# S3 bucket
bucket = "my-terraform-backend"
# AWS Region (required by the backend but also used for other resources)
region = "us-east-1"
# Enable DynamoDB server-side encryption?
encrypt = true
# DynamoDB Table Name
dynamodb_table = "my-terraform-backend"
# Environment Name
environment = "dev"
Terraform init should complete without issues as it happens with v0.13.0 and earlier versions (e.g. v0.12.28).
We declare a variable named "environment" in the given backend config file which is used for naming resources. I understand that I could create a separate var file for this but creating another file just for this seems overkill. Also we already have a convention that relies on this approach the makes use of the backend config file to include additional variables we use for several modules.
# terraform init -backend-config /config/backend.config
Initializing the backend...
Error: Unsupported argument
on ../../../config/backend.config line 21:
21: environment = "root"
An argument named "environment" is not expected here.
Steps required to reproduce the issue, for example:
terraform init -backend-config /config/backend.configThanks for reporting the issue, and I'm sorry that this change has affected your workflow. Some history on what caused this new validation to be added:
-backend-config override was not working (#24845), which was caused by attempting to use a full configuration file as an override.workspaces block. This made it impossible to use the backend config override with Terraform Cloud or Terraform Enterprise.The error you're seeing has a precedent in Terraform, as it's similar to when a *.tfvars file contains a value for unknown variables. That trade-off also makes some workflows more difficult, but the error is very valuable when it helps surface typos or other mistakes.
So at the moment, this seems to me like the best compromise we have for the backend config validation issue. As a result, I'm going to mark this issue as "working as designed". I do appreciate you sharing your feedback!
I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Most helpful comment
Thanks for reporting the issue, and I'm sorry that this change has affected your workflow. Some history on what caused this new validation to be added:
-backend-configoverride was not working (#24845), which was caused by attempting to use a full configuration file as an override.workspacesblock. This made it impossible to use the backend config override with Terraform Cloud or Terraform Enterprise.The error you're seeing has a precedent in Terraform, as it's similar to when a
*.tfvarsfile contains a value for unknown variables. That trade-off also makes some workflows more difficult, but the error is very valuable when it helps surface typos or other mistakes.So at the moment, this seems to me like the best compromise we have for the backend config validation issue. As a result, I'm going to mark this issue as "working as designed". I do appreciate you sharing your feedback!