resource/github_team: Add maintainers

[amitizle]

In case not using Admin account/token, the newly created team resource is created with 0 members, not allowing the service account / user account to proceed and add members, sub-teams or repos.

cc @caquino

[radeksimko]

Hi @amitizle
thank you for your PR and sorry for a small delay in reviewing it.

Before we move on, do you mind explaining the use case a bit further? Specifically I'm curious what permissions does the token/user have (and relationship to the org) that you're allowed to invite new maintainers during creation of the team, but not afterwards?

Do I understand correctly that you cannot achieve this via github_team_membership resource?

[amitizle]

Hey @radeksimko, no worries and thanks for the response.
Yes what you mentioned is more or less the use case.
If within an org I'm not an admin (global admin), I still can create a team.
If I'm creating the team via the Github web app it automatically adds me to the team as a maintainer, making is possible for me (as the maintainer) to invite more members.
Using the provider, it creates the team with no members and then me as the Terraform operator (either personal or a service account that is not a global admin) cannot add members.
So the plan phase succeeds, but the apply phase fails due to me not being able to add new members (neither myself) to the new team.

[radeksimko]

Do you mind listing all the scopes that you have set for your token?

Is it possible that as a user clicking in the UI, you have more permissions than the token (used by Terraform) has?

If that is not the case, then I'd be tempted to call this a bug and I'd probably raise it with GitHub support.

[amitizle]

I'll try to reproduce soon, with a new token and will post in here.

[steven-edgar]

I can confirm this bug report. This was creating a subteam within an organisation, with an API key with the following scopes

repo (all)
admin:org (all)
delete_repo

Account that created the API key is able to create subteams and add members without issue. The same terraform code, using the same API key, is able to add members to other teams without issue.

[radeksimko]

Thanks @steven-edgar for providing these details, that's helpful. I'll try to reproduce.

[radeksimko]

I spent some time trying to reproduce this. Here's the full list of steps I took:

---

Create a new personal token with the following scopes (as instructed above by @steven-edgar ) under my personal account (@radeksimko):

---

Just for completeness I am an Owner of the org - but I don't think it really matters in the context of any token.

---

Run GITHUB_TOKEN=... terraform apply (where ... is the token from previous step) with the following config:

provider "github" {
  organization = "terraformtesting"
}

resource "github_team" "my-team" { 
  name = "my-team" 
  description = "This is my team" 
  privacy = "closed" 
}

resource "github_team" "my-subteam" { 
  name = "my-subteam" 
  description = "This is my subteam" 
  privacy = "closed" 
  parent_team_id = "${github_team.my-team.id}" 
}

resource "github_team_membership" "my-team_github-user-1" { 
  team_id = "${github_team.my-subteam.id}" 
  username = "hashibot" 
  role = "maintainer" 
}

---

$ terraform apply

github_team.my-team: Creating...
  description: "" => "This is my team"
  name:        "" => "my-team"
  privacy:     "" => "closed"
github_team.my-team: Creation complete after 1s (ID: 2872296)
github_team.my-subteam: Creating...
  description:    "" => "This is my subteam"
  name:           "" => "my-subteam"
  parent_team_id: "" => "2872296"
  privacy:        "" => "closed"
github_team.my-subteam: Creation complete after 0s (ID: 2872297)
github_team_membership.my-team_github-user-1: Creating...
  role:     "" => "maintainer"
  team_id:  "" => "2872297"
  username: "" => "hashibot"
github_team_membership.my-team_github-user-1: Creation complete after 1s (ID: 2872297:hashibot)

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

---

I was therefore unable to reproduce this. Can please you provide further details? e.g. about the hierarchy of your teams in question?

Thanks.

[steven-edgar]

The team hierarchy is simply as described before, "my-team" doesn't reside under any other team. There are lots of other teams at the org level, but I'm not sure that's relevant. There were no other subteams under "my-team" at the time I created "my-subteam" the first time and encountered the zero members issue, I did create via TF a "my-subteam2" under "my-team", with the same results. I then manually created a subteam under "my-team", using the same account via the website, and used exactly the same terraform and API key as before, with the name of the subteam changed to match the manually created subteam, applied that and it applied the members correctly to the subteam.

The only other thing I can think of that might be relevant is the org requires SSO. The API key is enabled for SSO login, obviously, otherwise things wouldn't have got as far as they have.

Not sure what other details might be helpful for you.

[damacus]

Hey!

is there anything I can do to get this PR moving? I believe it's going to fix a bug I'm seeing when we add a team using a non-Organisation maintainer.

[carinadigital]

@radeksimko I think being the org owner, and not an org member is why you didn't see the bug.

Just for completeness I am an Owner of the org - but I don't think it really matters in the context of any token.

I work in a large github organisation. We manage a subset of teams and repos and have encountered the problem above. I'll try to get you a full set of reproducible steps.

It might be difficult to write a failing test for this as it depends on the permissions of the user the token relates to.

[karlgrund]

We are experiencing the same issue as described above. In a larger organization, you don't want to give a bot owner permissions to the organization. As it is now that bot can create a team, but it's not able to add anyone or itself to that team.

- module.team-test
  Updating source "modules/team"
module.team-test.github_team.main: Creating...
  description:    "" => "Team Test"
  etag:           "" => "<computed>"
  name:           "" => "team-test"
  parent_team_id: "" => "xxxxx"
  privacy:        "" => "closed"
  slug:           "" => "<computed>"
module.team-test.github_team.main: Creation complete after 1s
module.team-test.github_team_membership.members: Creating...
  etag:     "" => "<computed>"
  role:     "" => "member"
  team_id:  "" => "xxxx"
  username: "" => "karlgrund"

Error: Error applying plan:

1 error(s) occurred:

* module.team-test.github_team_membership.members: 1 error(s) occurred:

* github_team_membership.members: PUT https://api.github.com/teams/xxxx/memberships/karlgrund: 403 You must be an organization owner or team maintainer to add a team membership. []

This is the module that I'm using to create the output above.

resource "github_team" "main" {
  name           = "${var.team_name}"
  description    = "${var.team_description}"
  parent_team_id = "${var.parent_id}"
  privacy        = "${var.privacy}"
}

resource "github_team_membership" "members" {
  count = "${length(var.members)}"

  team_id  = "${github_team.main.id}"
  username = "${var.members[count.index]}"
  role     = "member"
}

We are using version 1.3.0 of the GitHub provider and this solution would unblock us.

[karlgrund]

I would add the label bug on this PR since you can only use this feature if you're an organization owner/admin.
@amitizle would you be able to have a look at the conflicts?

* github_team_membership.members: PUT https://api.github.com/teams/xxxx/memberships/karlgrund: 403 You must be an organization owner or team maintainer to add a team membership. []

[carinadigital]

I've resolved the conflicts with @amitizle PR at https://github.com/carinadigital/terraform-provider-github/tree/add_maintainer

I'm currently ensuring all the functionality and tests work.

[amitizle]

Hey friends, sorry for missing all of that! I was moving country, having a new baby and starting a new job :D

Can I help with this thing?

[carinadigital]

The current functionality won't work as intended.

There is no readMaintainers() like function on teams (https://godoc.org/github.com/google/go-github/github#Team). The current changes to the schema would introduce two places were we would be managing the same resource (github_team_membership and github_team maintainers attribute).

I'm in favour of taking a different direction with this. One option is to make a change to maintainer, so that it's only used at create time, and then not part of the terraform plans.

However, my preferred option is to mirror the functionality provided by GitHub UI where the user creating the team is automatically added as a maintainer. This solves our problem when we create teams when our terraform credentials are not the organisational owner credentials.

Something like

 resource "github_team" "foo" {
          name = "myfooteam"
          description = "foo"
          privacy = "secret"
          add_default_maintainer = true
  }

Once I have enough progress, I'll create a new PR and reference it here.

[carinadigital]

I've sought some guidance at https://github.com/terraform-providers/terraform-provider-github/issues/130 before starting, as the solution might be a little hacky.

[fmasuhr]

We are maintaining GitHub teams and memberships with an Github access token of an owner. In this case the user is automatically added as team member via the Github API as described here https://developer.github.com/v3/teams/#create-team.
But I think this is actually not a good practice for terraform as memberships are maintained additionally via the github_team_membership. The API is producing side effects which are not represented in the statefile.
The add_default_maintainer attribute proposed by @carinadigital could be a good way to solve this. In the case of add_default_maintainer = false the automatically added user membership should then be dropped again from the team. This will make sure there are no memberships created without adding them to the state.

[nickfloyd]

👋 Hey Friends, this issue has been automatically marked as stale because it has no recent activity. It will be closed if no further activity occurs. Please add the Status: Pinned label if you feel that this issue needs to remain open/active. Thank you for your contributions and help in keeping things tidy!