Creds for terraform cloud remote

[jmahowald]

I wasn't able to figure another way to be able to use terraform cloud for remote states, nor could I figure out if there is a general environment variable name to use for the terraform cloud token.

[hashicorp-cla]

All committers have signed the CLA.

[sudomateo]

This workflow is already covered in the examples here: https://github.com/hashicorp/terraform-github-actions/blob/master/examples/backends.md

Thank you for the work. The reason why I moved away from creating the .terraformrc file is because using -backend-config is more portable and configurable. For example in your pull request, there's no way to configure the hostname whereas using the -backend-config option will allow arbitrary backend configuration without code changes.

[jmahowald]

Thanks,

I might suggest to actually have a link on the main page of the github repo. When I wrote this the . It isn't clear in Terraform Cloud's remote docs how to do that. Also, when I wrote this, the docs at https://www.terraform.io/docs/github-actions/common-tasks/backends.html were using the previous workflow style, so I picked something that mirrored that behavior.

[jmahowald]

Actually, I have a follow up @sudomateo . I switched to use what was in that document, and init went through but it didn't seem to carry over to my plan. I also set in my env TF_API_TOKEN so that it's available to the plan. Is there something else I should do when running plan to make the credentials available if I ran init in the same job?

Error: Required token could not be found

Make sure you configured a credentials block for app.terraform.io in your CLI
Config File.```

[iniinikoski]

I might have a similar issue than you @jmahowald (even though my init does not even to through):

# tf init -upgrade -backend-config="token=<my working TFE token>" -backend-config="organization=<ORG>" -backend-config="hostname=<HOST>"
Upgrading modules...
- aws_networking_test in ..

Error: Error accessing remote module registry

Failed to retrieve available versions for module "label" (../main.tf:20) from
<HOST>: error looking up module versions: 401 Unauthorized.


Error: Error accessing remote module registry

Failed to retrieve available versions for module "label" (../main.tf:20) from
<HOST>: error looking up module versions: 401 Unauthorized.```

Terraform core version 0.12.16 here. I also create a Hashicorp support case out of this as my work is currently blocked :/

[iniinikoski]

Also, originally this support was here by @lkysow : #15 - but it was dropped off...

[sudomateo]

@jmahowald would you be able to provide the redacted Terraform files being used?

[sudomateo]

@iniinikoski it would be helpful to see how the label module is being called. The error by itself does not give all of the information without the actual code for context.

[iniinikoski]

@sudomateo sure. We just do this:

module "label" {
  source    = "<TFE_HOSTNAME>/<ORG>/label/terraform"
  version   = "0.4.0"
  namespace = var.host_project
  stage     = var.environment
  name      = "elasticsearch"
  delimiter = "-"

  tags = {
    "Project"     = var.project,
    "Environment" = var.environment,
    "Component"   = "elasticsearch",
    "Terraform"   = "true"
    "Region"      = data.aws_region.current.name
  }
}

[sudomateo]

@iniinikoski Thank you for providing that. After reading this documentation, it seems that the only way to authenticate to modules within a private module registry at this time is by using the CLI credentials file. I'll work on adding the CLI credentials file back into the code.

That being said I'm a bit curious as to where GitHub Actions fits into your workflow if you already are using Terraform Cloud/Enterprise. Care to share some details there?

[iniinikoski]

@sudomateo sure. I plan to use the Actions to test & verify modules - everything else is covered by TFE and it's PR-checking. I've never given a thought on plumbing the module repositories also to TFE workspaces. Hmm...

[sudomateo]

I plan to use the Actions to test & verify modules

@iniinikoski For clarity, when you say this, do you mean you are testing and validating modules using terraform fmt and/or terraform validate?

Also I have a branch named adding-cli-credentials-file located here if you would like to test it in your workflow. I tested it myself but would like to see if this covers your use case before I merge and release.

[iniinikoski]

@iniinikoski For clarity, when you say this, do you mean you are testing and validating modules using terraform fmt and/or terraform validate?

Both yes - and I need to do the init in between :)

Also I have a branch named adding-cli-credentials-file located here if you would like to test it in your workflow. I tested it myself but would like to see if this covers your use case before I merge and release.

Works like a charm, cool and thanks for the quick fix! :)

[sudomateo]

@iniinikoski Thank you for testing that. I released v0.6.3 to include this functionality. Also thank you for the details on your use case. I will discuss use cases like this internally to see if this is something we can begin to provide in Terraform Cloud/Enterprise.

[jmahowald]

Regarding why Github Actions and Terraform Cloud. I am actually trying both out, wanting to ensure the dev team that doesn't touch terraform much can do so with there standard pipeline tools, while weighing the workflow improvements of Terraform Cloud. But even if I don't use Terraform Cloud for the workflows, using the remote state is nice. I wish it would be easier to create a new workspace and set the management to local. (I'm aware that I can create something for this with using the TFE provider, but I'm talking about a simple command/flag)

[iniinikoski]

I wish it would be easier to create a new workspace and set the management to local. (I'm aware that I can create something for this with using the TFE provider, but I'm talking about a simple command/flag)

@jmahowald tfhelper (https://github.com/hashicorp-community/tf-helper) could help you here maybe, if the TFE provider does not...