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 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.test_policy_set.id
  workspace_id = 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, created another workspace, and attempt to attach this new workspace to the existing policy set from previous config
3. There is no way to attach new workspace to existing policy set,
4. After PR changes, attachment can be created with:

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

data "tfe_policy_set" "test_policy_set" {
  name = "my-policy-set"
  organization = "my-org"
}

resource "tfe_workspace_policy_set" "attachable_policy" {
  policy_set_id = data.tfe_policy_set.test_policy_set.id
  workspace_id = tfe_workspace.test_ws.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 add datasource for policy_set #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.

[brandonc]

When I re-apply a config containing a tfe_policy_set and a tfe_workspace_policy_set, the workspace_ids field is updated in-place, even if it does not appear in config

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # tfe_policy_set.test2 will be updated in-place
  ~ resource "tfe_policy_set" "test2" {
        id            = "polset-qBcEd8WAtFcxTKo6"
        name          = "test-policy-set-2"
      ~ workspace_ids = [
          - "ws-T2kxkEtyTGCdsKXX",
        ]
        # (4 unchanged attributes hidden)
    }

I think this can be fixed by adding Computed: true to this field.

You should also add documentation to this argument to say that the recommended way is to use the tfe_workspace_policy_set resource instead and those two cannot be used simultaneously. I think we did the same thing with tfe_variable_set?

[brandonc]

This is an invalid value for name-- can only include letters, numbers, -, and _

[brandonc]

make fmtcheck failed on this code, but that is curious because the linter passed. I think we should probably go ahead and add fmtcheck to the github action!

Everything else looks good

[Uk1288]

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

[brandonc]

I think the disparity is my local go version