[BUG]: Multiple `github_repository_collaborators` blocks interefere with eachother after creation

[spacez320]

Expected Behavior

When supplying multiple github_repository_collaborators blocks referencing the same repository, I would expect them to independently manage permissions against a repository on the first terraform apply. A follow-up terraform apply would then report "No changes".

Actual Behavior

Consider the following Terraform code:

resource "github_repository_collaborators" "collaborators_1" {
  repository = github_repository.repository.name

  user {
    permission = "triage"
    username   = "someone"
  }
}

resource "github_repository_collaborators" "collaborators_2" {
  repository = github_repository.repository.name

  user {
    permission = "pull"
    username   = "someone2"
  }
}

This does produce the following plan, and applies successfully.

Terraform will perform the following actions:

  # github_repository_collaborators.collaborators_1 will be created
  + resource "github_repository_collaborators" "collaborators_1" {
      + id             = (known after apply)
      + invitation_ids = (known after apply)
      + repository     = "something"

      + user {
          + permission = "triage"
          + username   = "someone"
        }
    }

  # github_repository_collaborators.collaborators_2 will be created
  + resource "github_repository_collaborators" "collaborators_2" {
      + id             = (known after apply)
      + invitation_ids = (known after apply)
      + repository     = "something"

      + user {
          + permission = "pull"
          + username   = "someone2"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

Immediate running another apply with no changes does this:

Terraform will perform the following actions:

  # github_repository_collaborators.collaborators_1 will be updated in-place
  ~ resource "github_repository_collaborators" "collaborators_1" {
        id             = "something"
      ~ invitation_ids = {} -> (known after apply)
        # (1 unchanged attribute hidden)

      - user {
          - permission = "pull" -> null
          - username   = "someone2" -> null
        }

        # (1 unchanged block hidden)
    }

  # github_repository_collaborators.collaborators_2 will be updated in-place
  ~ resource "github_repository_collaborators" "collaborators_2" {
        id             = "something
      ~ invitation_ids = {} -> (known after apply)
        # (1 unchanged attribute hidden)

      - user {
          - permission = "triage" -> null
          - username   = "someone" -> null
        }

        # (1 unchanged block hidden)
    }

Plan: 0 to add, 2 to change, 0 to destroy.

If you apply this, all users are removed from the repository. It's almost like the provider thinks each block is the same resource?

A work-around is to use a single github_repository_collaborators block for all user and team assignments, but judging from the documentation it doesn't seem like this is intentional.

Terraform Version

Terraform v1.13.3
on darwin_arm64

• provider registry.terraform.io/hashicorp/aws v6.32.1
• provider registry.terraform.io/integrations/github v6.11.1

Affected Resource(s)

• github_repository_collaborators

Terraform Configuration Files

n/a

Steps to Reproduce

See actual outcome.

Debug Output

n/a

Panic Output

n/a

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

👋 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 labeled with Status: Up for grabs. You & others like you are the reason all of this works! So thank you & happy coding! 🚀

[deiga]

@spacez320 https://registry.terraform.io/providers/integrations/github/latest/docs/resources/repository_collaborators

This resource is authoritative. For adding a collaborator to a repo in a non-authoritative manner, use github_repository_collaborator instead.

You are supposed to either use github_repository_collaborator if you want to manage single users without resetting the state or use multiple user blocks in github_repository_collaborators

[spacez320]

@deiga Thanks for the response. I can appreciate that this is the way the resource is designed, but I'd suggest some things:

1. The documentation should make the singleton nature of this resource a little clearer. I can see a couple of passages in the resource docs that maybe hint towards it, but obviously I was fooled.
2. The provider should really throw an error if you try to use more than one of these resources.

I will say though, not that I know the depth and breadth of Terraform resources, but I can't think of any other that works this way.

[deiga]

Granted, the docs could be better. The style is a bit too casual and doesn't stress the authorative part enough.

The problem with "should throw an error" is that Terraform doesn't have a way to deal with such a situation as resources don't know of each other. The resource ID is AFAIK the only tool with which it's possible to impact other resources, but that is set in create and can't be validated in plan.

Having authorative resources is a fairly common pattern especially for resources which deal with some form of ACL.
The gcp provider has authorative resources for IAM things, as well as the AWS provider.