Terraform init in CI with a fresh environment

[cemo]

Terraform Version

1.7.0

Use Cases

In Github Actions we would like to create or select a workspace.

Attempted Solutions

terraform init -select-or-create -workspace=my-existing-or-new-workspace

Proposal

terraform {
  cloud {
    organization = "my-organization"

    workspaces {
      tags = ["app:myapplication"]

    }
  }
}

This result:

    /my/path # terraform init
    Initializing Terraform Cloud...
    No workspaces found.
    There are no workspaces with the configured tags (app:myapplication) in your Terraform Cloud organization. To finish initializing, Terraform needs at least one workspace available.
    Terraform can create a properly tagged workspace for you now. Please enter a name to create a new Terraform Cloud workspace.
    Enter a value:

The problem is in CI environment having a non-interactive shell cause troubles and forcing users to create a default or that environment locally.

Another solution is using custom api scripts to create workspace by API calls.

I think all these solutions are not intutitive and cause troubles and extra work. Having a parameter like select command or

terraform init -select-or-create -workspace=my-existing-or-new-workspace

References

No response

[crw]

Thanks for this feature request! If you are viewing this issue and would like to indicate your interest, please use the 👍 reaction on the issue description to upvote this issue. We also welcome additional use case descriptions. Thanks again!

[cemo]

@apparentlymart @crw I think this can be considered as a bug since without a default workspace it raises error. The workaround is creating a default workspace for each tag + workspace name and this is pretty much annoying.

In order to reproduce problem please init a fresh workspace which has a tag with -input=false to simulate a CI environment.

[apparentlymart]

In our process the "enhancement" label represents changes to Terraform's technical design, while "bug" represents fixing situations where Terraform's implementation differs from its design. This separation is important because issues in each category require a different sort of work, sometimes different people to work on them, etc.

The Terraform Cloud integration was designed to require at least one matching workspace to exist as a compromise because traditional Terraform backends deal with this situation by implicitly creating a workspace named "default", but that approach would not be appropriate in Terraform Cloud. The Terraform Cloud integration is working as designed, even though we might disagree with that design.

I agree that the current design would be annoying if you primarily work in Terraform CLI and expect to be able to start from that point. Many Terraform Cloud customers seem to create their workspaces prior to using Terraform CLI with them, using either the web UI, the hashicorp/tfe provider, or directly with the API, and so I assume the current design was made with that assumption in mind. The Terraform Cloud teams will need to consider how and whether to support this new possibility of having all workspaces created by Terraform CLI when using the Terraform Cloud integration. This issue therefore primarily needs some design input from Terraform Cloud teams.

Your proposal of having Terraform CLI optionally automatically create and use a specific workspace name during terraform init does seem reasonable to me on the surface, and if the Terraform Cloud teams agree that it's a reasonable usage pattern then it could also potential allow loosening the requirement in traditional backends of always having a workspace named "default", since that restriction exists mainly to avoid a non-Terraform-Cloud version of this same error.

(That won't necessarily be straightforward to achieve, because some backend implementations unfortunately also rely on there always being a default workspace for their own purposes. For example, the s3 backend stores the default workspace differently than the others because its design predates the idea of having multiple workspaces. But it'll be something we should consider as part of designing this if we do decide to move forward with the idea of implicitly creating workspaces as part of terraform init, since we'll need to figure out what the new option ought to do when not using the Terraform Cloud integration too.)

[cemo]

Thank you for explanation as always.

I think init was much time ago implemented than terraform cloud config and after bringing tags support in the cloud config, this part might be missed. Having only only one empty default workspace is fine for many people but in our current situtation, it requires default workspace per tag. Terraform itself recommending to have small workspaces and this requires us to create many not usable workspaces.

By the way I tackled this problem by calling API manually to create workspace before starting operation. It is ugly but working.