hashicorp / terraform

Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
https://www.terraform.io/
Other
42.71k stars 9.55k forks source link

TF_CLI_ARGS or similar support for -chdir #28037

Open OJFord opened 3 years ago

OJFord commented 3 years ago

Current Terraform Version

0.14.7

Use-cases

-chdir is a big help for repositories where terraform config is in a subdirectory.

But probably, if you want it at all, you want it always (with a given project), so it would be helpful to be able to set it once, perhaps with a tool like direnv (so that it's always set within that directory pointing at the subdirectory).

Attempted Solutions

This is currently not possible, at least not with an environment variable, and so not with anything like direnv, because $TF_CLI_ARGS (and sub-command specific variants) are injected after the subcommand, whereas -chdir must come before them.

For example:

$ TF_CLI_ARGS='-chdir=foo' terraform init

is equivalent to:

$ terraform init -chdir=foo

which will error with usage.

Proposal

Any of (in no particular order; numbered for convenience of discussion):

  1. Introduce a $TF_CLI_GLOBAL_ARGS (though -chdir is at present the only such option you'd ever want to set)
  2. Introduce a $TF_CLI_CHDIR
  3. Add logic around $TF_CLI_ARGS & $TF_CLI_ARGS_* to put global and sub-command options in the correct place
  4. Allow -chdir, or global options in general, to come in any position (there are not presently any conflicts, and that would not be a great UX decision anyway, I suppose)

References

I mentioned this previously in https://github.com/hashicorp/terraform/issues/22734#issuecomment-788865551, but noticing the information about and push toward -chdir in v0.15.0-beta1 release notes, I thought it might be worth calling out separately.

lexuzieel commented 3 years ago

I just stumbled upon this issue myself while trying to define -chdir as an environment variable using direnv. Maybe I am using terraform wrong somehow, but I don't want to clutter my main project directory with *.tf files, so adding an ability to specify this as an environment variable would at least make it possible to sort of define project options using other tools (i.e. direnv)

rjcoelho commented 3 years ago

Same issue here Workaround

alias terraform="`which terraform` -chdir=$TF_CLI_CHDIR"`
koistya commented 2 years ago

Note that in Google Cloud CLI you can use global arguments before or after any command:

$ glcoud --project=example functions list --region=us-central1
$ gcloud functions list --region=us-central1 --project=example

...which can be used for inspiration as a high-quality CLI tool.

OJFord commented 2 years ago

in Google Cloud CLI you can use global arguments before or after any command which can be used for inspiration

Yes that's proposed solution#4.

meetmatt commented 1 year ago

Hello maintainers! Thank you for tremendous work. Is there a slight chance you might get back to this issue? Thanks in advance <3

meetmatt commented 1 year ago

Take a look at TF_ROOT implementation from GitLab as described here: https://docs.gitlab.com/ee/user/infrastructure/iac/gitlab_terraform_helpers.html#generic-variables

deepbrook commented 1 year ago

Adding to this here:

I ran into this issue as well, and I was actually under the impression that TF_CLI_ARGS is for the root command's flags (i.e. terraform) and TF_CLI_ARGS_* was for the terraform sub-command's flags.

So, I was running this and expected it to work:

🐟 ❯ env TF_CLI_ARGS_plan="-no-color" TF_CLI_ARGS="-chdir=$PWD/deploy" terraform plan

Error: Failed to parse command-line flags

flag provided but not defined: -chdir

For more help on using this command, run:
  terraform plan -help

on ⛵ dev () gitlab-ci-terraform on  main ☁️ default
[🔴 ERROR] 🐟 ❯

The other proposed solutions are just as good for me. Just wanted to point out that it confused this devops engineer here (albeit due to skimming over the docs and not reading them properly).