-
Notifications
You must be signed in to change notification settings - Fork 748
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
[BUG]: github_team_members
Fails to Differentiate between Members and Child Team Members
#2004
Comments
👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labled with |
Hey @kfcampbell thanks for triaging this and I can see its made it in to your backlog. Can definitely appreciate that your team has quite a few other items in there as well - can you give me a sense of when/if someone might be able to take a closer look at this? This is part of an on-going body of work that my team is engaged in, so it would be nice to know if we can wait until your team is able to resolve this issue or if we should start brainstorming another approach to achieve our goals. I'm not looking for a specific commitment so much as to get a better idea of how incoming work moves through your backlog |
I'm abroad right now and it's almost midnight, but just wanted to throw this out here in case it helps with the issue. IIRC the GitHub API itself (backend, not |
@o-sama thank you for the thoughts! @GarrettBlinkhorn unfortunately GitHub's SDK team does not have the bandwidth now to prioritize and pick up new features. Community discussion and PRs are very much appreciated! |
@kfcampbell isn't this the same as #1193, which was marked as completed via #1786? Am I missing something? |
@murukesh-mohanan-paidy I believe it is, thanks for bringing it up. I'm going to close this for now but we can reopen or open a new issue if this rears its head again. |
Expected Behavior
I am currently importing an existing set of Github teams into Terraform management using this provider. After I import the team to my
github_team_members
resource, I expect that theterraform plan
will returnNo changes required.
because I have defined amembers
variable which assigns all of the relevant team members and their roles to the resource.No changes required.
is therefore the happy state which indicates a successful import of the existing team into Terraform management.Actual Behavior
This bug only occurs in a situation where you have a child team that has members that are not members of the parent team.
For clarity and as an example,
ParentTeam
containsUserA, UserB
andChildTeam
containsUserA, UserC
.In the above case, the
terraform plan
actually returns a plan indicating that Terraform intends to removeUserC
from thegithub_team_members.ParentTeam
resource.This is unexpected because
UserC
has never been a member ofParentTeam
so they shouldn't need to be removed. If you accept the plan and carry on with aterraform apply
to confirm the removal, Terraform will make the modifications like such:However, a subsequent
terraform plan
will still return the original result: a plan which will attempt to remove theUserC
fromParentTeam
. Therefore, it is impossible to use this resource to properly manage a parent team when one of the child teams has members that do not exist in the parent team, as you end up stuck with a plan trying to remove an individual membership that doesn't actually exist and thus you can never reach theNo changes required
happy state.Through my own attempts to debug this issue, I've learned the following:
UserC
and add them tovar.members
which is used to generate theParentTeam
github_team_members
, then Terraform will returnNo changes required.
even thoughUserC
will not actually show up asParentTeam
team member. This "solves" the plan but actually makes the situation more confusing, becauseUserC
is defined as a member ofParentTeam
in code but not in reality. I would expect that any user defined using themember
block would be a member of the team.members
andchild team members
- thegithub
provider though does not seem to make this distinction, which I suspect is why the provider treats them like an actualmember
instead.Terraform Version
Terraform v1.5.2
MacOS Ventura 13.6
Affected Resource(s)
Terraform Configuration Files
Steps to Reproduce
First, create two Github teams (a Parent and a Child subteam) where the Child subteam has a team member that is not a member of the Parent team. For example,
ParentTeam
containsUserA, UserB
andChildTeam
containsUserA, UserC
.Then, run a
terraform plan
againstParentTeam
. The plan should return an attempt to removeUserC
fromParentTeam
as described above. I've included my configuration files so I hope that reproducing this error is not too much effort.Debug Output
These logs correspond to the provided example:
Panic Output
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: