Add ability to attach a workspace to an existing policy set

[Uk1288]

Description

Currently the lifecycle of the tfe_policy_set requires that all tfe_workspace resources are created first and then assigned in one call to the tfe_policy_set during creation of the policy. For example:

resource "tfe_workspace" "test_ws" {
  name         = "test_ws"
  organization = "my-org"
  tag_names    = ["test", "app"]
}

resource "tfe_policy_set" "test_policy_set" {
  name          = "my-policy-set"
  description   = "A new policy set"
  organization  = "my-org"
  workspace_ids = [tfe_workspace.test_ws.id]
}

Consider the case where tfe_workspace resources are spread across multiple got repositories. Where each team or repo wants to be able to create & attach workspaces to existing policy sets. For example,

team-security is in charge of creating policies and own security-repo having:

resource "tfe_policy_set" "test_policy_set" {
  name          = "my-policy-set"
  description   = "A new policy set"
  organization  = "my-org"
  workspace_ids = []
}

team-dev wants to create its workspaces in dev-repo but attach it to existing policies above:

resource "tfe_workspace" "test_ws" {
  name         = "test_ws"
  organization = "my-org"
  tag_names    = ["test", "app"]
}

***no way to attach to existing policy set except by duplicating the policy set creation

User pain point: This leads to each repo re-creating the same policy unnecessarily.

This PR adds tfe_workspace_policy_set which allows workspaces to be attached to existing policy sets.

resource "tfe_workspace" "test_ws" {
  name         = "test_ws"
  organization = "my-org"
  tag_names    = ["test", "app"]
}

resource "tfe_workspace_policy_set" "attachable_policy" {
  policy_set_id = data.tfe_policy_set.readable_policy_set.id
  workspace_id = data.tfe_workspace.test_ws.id
}

Note: Since workspaces can be added across multiple repos to the same policy set, this means the policy-set state can be altered by various configs(repos). Similar behaviour with tfe_workspace_variable_set

Remember to:

• Update the Change Log

• Update the Documentation

Testing plan

1. Create a workspace and a policy set in a config
2. Create a second config, read the previously created workspace & policy set, and attempt to attach the workspace to the existing policy set
3. There is no way to create an attachment,
4. After PR changes, attachment can be created with:

resource "tfe_workspace_policy_set" "attachable_policy" {
  policy_set_id = data.tfe_policy_set.readable_policy_set.id
  workspace_id = data.tfe_workspace.wk-1.id
}

External links

Include any links here that might be helpful for people reviewing your PR. If there are none, feel free to delete this section.

• API documentation
• Depends on Related PR and dependent PR https://github.com/hashicorp/terraform-provider-tfe/pull/592

Output from acceptance tests

Please run applicable acceptance tests locally and include the output here. See TESTS.md to learn how to run acceptance tests.

If you are an external contributor, your contribution(s) will first be reviewed before running them against the project's CI pipeline.

$ TESTARGS="-run TestAccTFEWorkspacePolicySet" make testacc

...

[annawinkler]

Could you clarify the note in the PR description:

Since workspaces can be added across multiple repos to the same policy set, this means the state can be changed outside a particular config and however, the config should re-sync after an apply. Similar behaviour with tfe_workspace_variable_set

I don't think I understand the implication of what is being said here. 🤔

[Uk1288]

Could you clarify the note in the PR description:

Since workspaces can be added across multiple repos to the same policy set, this means the state can be changed outside a particular config and however, the config should re-sync after an apply. Similar behaviour with tfe_workspace_variable_set

I don't think I understand the implication of what is being said here. 🤔

I have added a more detailed explanation. Take a look and let me know if it makes more sense.

[Uk1288]

That's interesting, I just did a make fmtcheck on this branch and no errors. What errors are you seeing?