terraform-provider-github: github_repository_collaborator broken since v2.8.0

Since github provider v2.8.0 the github_repository_collaborator resource is broken. It fails with User <username> is already a collaborator. In v2.7.0 this worked as expected.

Terraform Version

v0.12.25

Affected Resource(s)

github_repository_collaborator

Terraform Configuration Files

resource "github_repository" "my_repo" {
  name        = "my_repo"
  private     = true
  description = ""
}

resource "github_repository_collaborator" "user_foobar" {
  repository  = github_repository.my_repo.name
  username   = "foobar"
  permission = "pull"
}

Panic Output

Expected Behavior

What should have happened?

The collaborator should be added to the repository and the resource should be in the state.

Actual Behavior

What actually happened?

The collaborator gets added to the repository with the correct permissions, but terraform fails with this error and the resource is not in the state.

Error: User foobar is already a collaborator

  on test.tf line 7, in resource "github_repository_collaborator" "user_foobar":
  7: resource "github_repository_collaborator" "user_foobar" {

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

terraform apply

Important Factoids

References

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 22
Comments: 15 (5 by maintainers)

Most upvoted comments

Hello @anGie44 can we release the 2.9.3 version with this bugfix before 3.0.0? Thanks in advance

+10

carbohydrates on Aug 21, 2020

I also have this issue with repo collaborators that are managed by Terraform via this provider. Applying the plan creates the collaborators on the repo but then causes the errors noted in this issue.

If you then import the resource into the state and rerun the plan the infra is up to date and not changes are detected. Hopefully this gets fixed soon.

dennasolon on Jul 14, 2020

Edit: If you want the short version, @jcudit wrote it up here. My take is that the GitHub API documentation is incomplete and 204 should be accepted as an OK until it’s fixed/updated. (Which means a manual check needs to happen before the collaborator is added.)

I was able to reproduce the issue with

Terraform 0.12.26 provider.github v2.8.1

Test

User is a member of the organization
User was not affiliated with the repo before (the admin was trying to add user to the repo)
During multiple tests, the user was added with “pull”, “push”, “triage”, “maintain”, “admin” permissions

Result

In each case the expected permission is set in GitHub. (Good!)
In each case, Terraform reports the “User X is already a collaborator” error. (Bad)

Additional test

I added the user to the repo as a collaborator outside of Terraform
I reran the Terraform code multiple times with different permission set

Additional Result

Terraform reported that the user is already a collaborator (Good!)
GitHub showed that the user permissions changed in line with the Terraform code (Weird/Bad from a Terraform perspective)

My understanding is that GitHub reports back with a 204 to every command and that is considered an error in Terraform: https://github.com/terraform-providers/terraform-provider-github/blob/master/github/resource_github_repository_collaborator.go#L77 I think GitHub never really had any internal errors about the request, it’s just that 204 is the default response to any changes.

Troubleshooting details According to the GitHub API description on adding collaborators, there are two possible responses to the call:

201 (and some content), if an invitation was sent to the invited GitHub user
204 if the user is already a collaborator

What the API documentation fails to mention (at least in my case), is that if a user is a member of my organization, the user will not need an invitation to be added as a collaborator to a repository within the organization.

So, my assumption is that since the user doesn’t need an invite, a 201 response would be inappropriate. The only other defined response is 204 and for whatever reason, GitHub API chooses to send that in each OK case. This suspicion is further advanced by the “Remove a repository collaborator” documentation below in the API, which also responds with 204 if the collaborator was successfully removed.

In short: the GitHub API documentation fails to mention that 204 is reported in any regular case.

What’s worse, it seems to execute the request properly, before reporting 204, even when the user is really a collaborator on the repo.

Additional note: the call to GitHub AddCollaborator seems fine.

Proposed solution Assume that 204 == OK. This seems to be a shortcoming of the GitHub API documentation.

In resourceGithubRepositoryCollaboratorCreate, check if the user is already added to the repo as a collaborator, with the correct permission. (With this API call.)
If the user is already added, error out. (As is expected by Terraform for non-managed resources.)
If the user is not added call AddCollaborator.
If the response is not 204 (or 201, I guess, I’m not sure where that’s checked), error out. (Opposite of current check.)

greg-szabo on Jun 14, 2020

Personally, I’d prefer never erring and only giving warnings. If I have a user that has access to the repo already (say through a team), but we want to give this single user (not the whole team) more access, I’d want to be able to do that through the github_repository_collaborator step. So, if the user already has access to the repo but with LESS permissions than the Terraform is trying to add, then the permissions should update to reflect Terraform.

emmahsax on Jun 18, 2020

@tpatzig by outside does that also mean the user is not part of a team within the org and the org has Base Permissions set to None? I was also able to reproduce this scenario in v2.8.0 and not v2.7.0 by adding a completely new user foobar (outside org and not the user authenticated with the provider) first to a team that lives within an org (org has Base Permissions set to None so private repos are not visible from the new user’s perspective even while in the team), and then I attempted to add the new user as a collaborator and got the error Error: User foobar is already a collaborator in v2.8.0

anGie44 on Jun 2, 2020