New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add projects support #704
Add projects support #704
Conversation
fdaf4b6
to
1034717
Compare
@@ -0,0 +1,109 @@ | |||
package tfe | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the markdown docs, project.html.markdown
is missing, is there a plan to add that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I just pushed it and added a preview to the PR description.
d4004cb
to
59a2473
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good! Thank you for doing the text clean up along side.
One small comment, the commits history can be squashed to keep the history minimal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having the project_id in the workspace creates an interesting co-dependency when destroying project resources. You have to apply two plans:
- change all tfe_workspace.project_id to some other project
- remove the project to destroy it
One potential way to resolve this is to have a relationship resource tfe_workspace_project which, upon destruction, changes to the org default or something. That would usually get destroyed before the project. I don't think it's necessary and may be even more cumbersome than the project_id field.
This is great! I didn't find anything
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One tiny thing I found was that the default_project_id is set as optional, but configurations ought not set it because it's always computed.
"Computed" alone means that it's not allowed in the configuration at all, which is what we probably want here. If a user sets this to something arbitrary, you get Error: Provider produced inconsistent final plan
after the API computes it.
7a10a0f
to
d6c9e63
Compare
The makefile used to have a target for generating docs, but it broke a long time ago. Since no one has fixed it for a long time, it must not be that critical. Removing it, so that it doesn't confuse contributors.
d6c9e63
to
87cd343
Compare
@mwudka is there any intention to add the ability to manage project access for teams to this before it goes GA? We are a paid TF Cloud customer that is using the projects private beta, and something that seems to be missing from this resource is the ability to manage access to the project. Should I open a new issue for that functionality or go through the beta process to request it? |
I've created a feature request in this repo to reinforce that project support is incomplete without a team access resource. Support for project/team access was just merged into our go SDK today so I assume that a provider resource is forthcoming. |
Description
IMPORTANT: Before merging, upgrade to a go-tfe release that includes hashicorp/go-tfe#564.
Add support for projects (currently in beta). Introduces a new
tfe_project
resource, which allows creating projects. Also introduces a newproject_id
attribute on workspaces, to allow creating workspaces within specific projects.Testing plan
Docs preview
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.