Use graphql rather than rest API for Github team membership

[joshua9519]

This change should provide better diffing for team members for teams with child teams. Currently, child team members are included in the parent team's members list and so diffs are incorrect.

See Issue 1193.

Resolves #1193

---

Behavior

Before the change?

Currently, child team members are included in the parent team's members list and so diffs are incorrect.

Say we have a team team-a, with members user-1 and user-2 and child teams team-b - with user-3 as a member - and team-c - with user-4 as a member - then we expect to see only the members user-1 and user-2 in the diff of team membership resource. However, we instead see user-3 and user-4 in the diff as needing to be removed.

After the change?

Using the graphQL API rather than the rest API for reading the team members allows us to specify that we only want users with immediate membership.

Other information

---

Additional info

Pull request checklist

• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)
• Added the appropriate label for the given change

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes (Please add the Type: Breaking change label)
• No

If Yes, what's the impact:

• N/A

Pull request type

Please add the corresponding label for change this PR introduces:

• Bugfix: Type: Bug
• Feature/model/API additions: Type: Feature
• Updates to docs or samples: Type: Documentation
• Dependencies/code cleanup: Type: Maintenance

---

[kfcampbell]

This PR is causing integration test failures for me locally:

    testing.go:705: Step 0 error: Check failed: Check 1/2 error: team has not one member: 0

Can you reproduce this?

[joshua9519]

This PR is causing integration test failures for me locally:

    testing.go:705: Step 0 error: Check failed: Check 1/2 error: team has not one member: 0

Can you reproduce this?

Hi @kfcampbell I can run the tests but I feel like I am struggling with the test setup required for this PR because I am seeing that error on the main branch as well as on my branch... I have a test organisation and I even made a test user but can't seem to get the setup to work with the correct env vars etc.

Could I get some guidance?

Thank!

[jsifuentes]

Hi. I ran into the issue that required this PR, so I'm interested in getting this merged. I ran the acceptance test locally and ran into the same issue @kfcampbell described, but I think the issue stems from the fact that team membership is not returned on the API if organization membership has not been accepted yet. This comment in the original PR for github_team_members also shows that testing this feature was not straightforward back when it was merged: #975 (review)

Gave this a spin locally but found it difficult to test given the whole invite-another-collaborator flow. Looks good on another read through though and feel we can ship and iterate if needed.

The way I got my acceptance test to run successfully locally is by setting env GITHUB_TEST_COLLABORATOR to a user that already exists in the organization as a member. Then when the API returns team membership, it seems to appear correct and the test passes.

[joshua9519]

I can confirm that @jsifuentes is absolutely right and the only way to make this test work is by using a user that you have already added to the organization as a member. I have done this and it works and tests pass. I'm not sure how the maintainers wish to proceed on this.

@kfcampbell do you have any thoughts?

[kfcampbell]

Thank you both! I've been able to confirm acceptance tests are passing now. I appreciate the work here!

[csainty]

This doesn't appear to do paging, cutting off teams at 100 members and making the plan think it needs to add a bunch of new members.
Investigating a fix locally, but I'm no Go expert and lack a ready test environment. So sending a heads up.