Add exclusive_tags parameter to Workspace Resource

[mbillow]

Description

Currently, workspaces managed by Terraform cannot have externally managed tags. We are currently attempting to automate certain tags on our workspaces to better surface relevant metadata. Unfortunately, this causes conflicts with Terraform because it wants to control all tags on the workspace.

Remember to:

• Update the Change Log
• Update the Documentation

Testing plan

1. Create a workspace resource with exclusive_tags set to false.
2. Manually add an additional tag to the workspace via the UI or API.
3. Run a terraform apply to ensure that no changes are detected.
4. Delete a controlled tag manually.
5. Run a terraform apply to ensure that the controlled tag is recreated.

Output from acceptance tests

terraform-provider-tfe on ⎇ ignored-tag-names via 🐹 v1.21.1 on 🐳 v25.0.2 took 34.0s 
➜ TFE_TOKEN="" TESTARGS="--run TFEWorkspace_changeTags" make testacc 
TF_ACC=1 TF_LOG_SDK_PROTO=OFF go test $(go list ./... |grep -v 'vendor') -v --run TFEWorkspace_changeTags -timeout 15m
?       github.com/hashicorp/terraform-provider-tfe     [no test files]
testing: warning: no tests to run
PASS
ok      github.com/hashicorp/terraform-provider-tfe/internal/client     (cached) [no tests to run]
testing: warning: no tests to run
PASS
ok      github.com/hashicorp/terraform-provider-tfe/internal/logging    (cached) [no tests to run]
?       github.com/hashicorp/terraform-provider-tfe/version     [no test files]
=== RUN   TestAccTFEWorkspace_changeTags
2024/02/09 12:51:44 [DEBUG] Configuring client for host "app.terraform.io"
2024/02/09 12:51:44 [WARN] Unable to read CLI config or credentials file /Users/mbillow/.terraformrc: open /Users/mbillow/.terraformrc: no such file or directory
2024/02/09 12:51:44 [DEBUG] Service discovery for app.terraform.io at https://app.terraform.io/.well-known/terraform.json
--- PASS: TestAccTFEWorkspace_changeTags (34.74s)
PASS
ok      github.com/hashicorp/terraform-provider-tfe/internal/provider   35.396s

[brandonc]

@mbillow Hey, Marc. Thanks for the contribution. I think that this feature doesn't allow terraform to follow the 'standard' behavior of the config being the source of truth for a particular resource attribute, but I also totally get that tags often require a special flexibility.

I needed to make a couple of changes to this PR in order to make it mergable, notably, the [default] value of false needs to retain the current behavior to remain compatible with all the existing config. But also I felt that the argument name was not quite explicit enough. So I took your code and re-opened this as #1254 (And added you as a co-author)

I still need to run this by a few others but this should probably appear in the next release. Thanks again!

[mbillow]

I felt that the argument name was not quite explicit enough. So I took your code and re-opened this as #1254

You also have the permission to push to this branch of my fork, as a collaborator on the repository. I get not wanting to manage spurious remotes though.

I needed to make a couple of changes to this PR in order to make it mergable, notably, the [default] value of false needs to retain the current behavior to remain compatible with all the existing config.

The default value in this branch does retain the existing functionality: exclusive_tags = true causes the provider to overwrite all tags.

When it was renamed in your branch the new name and implementation should, and does, default to true: ignore_additional_tag_names = false.

I think that this feature doesn't allow terraform to follow the 'standard' behavior of the config being the source of truth for a particular resource attribute, but I also totally get that tags often require a special flexibility.

I agree that this is suboptimal, but its necessity is rooted in TFE's lackluster implementation of workspace metadata / tagging. For instance, key value metadata would have allowed us to accomplish our task with ignore_changes lifecycle arguments.

---

Nonetheless, thanks for taking a look. I'll close this for now and keep an eye on the other PR.

[brandonc]

@mbillow I see- I overlooked the schema default in your change that creates the reasonable behavior. I forgot to mention that I also pulled the change into the hashicorp repo so we could use the test infra.