Adding support for the resource_count attribute on tfe_workspace

[annawinkler]

Description

This PR exposes the resource_count attribute on the tfe_workspace resource. This is to make it easier for users writing a Sentinel policy to prevent workspaces from being deleted prior to deleting all of the resources that belong to the given workspace. This attribute is already exposed as part of the data source call.

Below is a screenshot of the documentation update on the tfe_workspace resource:

Testing plan

1. Create a new workspace using the configuration below

resource "tfe_organization" "test-organization" {
  name  = "my-org-name"
  email = "[email protected]"
}

resource "tfe_workspace" "test" {
  name         = "my-workspace-name"
  organization = tfe_organization.test-organization.name
  tag_names    = ["test", "app"]
}

output "workspace_resource_count" {
  value = tfe_workspace.test.resource_count
}

This should yield a result like this:

$ terraform refresh
...
Outputs:

workspace_resource_count = 0

2. Inside the new workspace (ie my-workspace-name), use the following configuration (or similar) to add resources under the control of the workspace:

resource "tfe_team" "test" {
  name         = "my-team-name"
  organization = "my-org-name"
}

3. Back on the original workspace, re-run a terraform refresh so we can now see that the resource_count has changed from 0 to 1:

$ terraform refresh
...
Outputs:

workspace_resource_count = 1

External links

• Related Issue

Output from acceptance tests

$ TF_ACC=1 TF_LOG_SDK_PROTO=OFF envchain tfe-staging go test ./... -v -run TestAccTFEWorkspace

[uturunku1]

Sorry if I missed this information, but what was the reason not to the use the original PR opened by the external contributor, and push your commit there? If we are merging this PR instead, would it be possible to @ the contributor to the changelog to thank him for these changes? 🙏
This PR looks good to me, thanks for adding the test!

[annawinkler]

Sorry if I missed this information, but what was the reason not to the use the original PR opened by the external contributor, and push your commit there? If we are merging this PR instead, would it be possible to @ the contributor to the changelog to thank him for these changes? 🙏 This PR looks good to me, thanks for adding the test!

Good questions! For go-tfe, we have a script that rebases forks and opens a new PR so we can run the tests. I wanted to make sure the test issues with the original PR were unrelated to auth problems, so I manually followed a similar process to what we're doing in go-tfe.

I forgot to add the contributor to the changelog entry - I'll do that. Oh - interestingly the TFE provider changelog doesn't indicate who added PRs - do we want to start doing that? I've referenced their PR though, so perhaps that's sufficient?

I added comments to the original PR to rebase and update the changelog.

We had added a comment to the PR indicating that we would help with the tests, and I prefer to either give a diff suggestion or to have a separate branch instead of committing to someone else's branch (unless they explicitly OK me committing to their branch).

[uturunku1]

About your comment interestingly the TFE provider changelog doesn't indicate who added PRs - do we want to start doing that?, yes, I think it would be nice to add the name of the external contributor, if this doesn't get added automatically 😊

[annawinkler]

I agree with you! I'll add that.