[BUG]: github_organization_role_team resource causes permanent drift in github_repository_collaborators

[christianfaucher]

Expected Behavior

After running "terraform apply", the "github_repository_collaborators" resource should not detect any drift.

Actual Behavior

After running "terraform apply", every subsequent plan or apply detects drift in the "github_repository_collaborators" resource.

Example:

  # github_repository_collaborators.some_repo_collaborators will be updated in-place
  ~ resource "github_repository_collaborators" "some_repo_collaborators" {
        id             = "some-repo"
        # (2 unchanged attributes hidden)

      - team {
          - permission = "pull" -> null
          - team_id    = "16178939" -> null
        }

        # (1 unchanged block hidden)
    }

We have this behavior in a GitHub Enterprise Cloud EMU environment without data residency.

Terraform Version

Terraform v1.14.4
on darwin_arm64

• provider registry.terraform.io/integrations/github v6.11.0

Affected Resource(s)

• github_repository_collaborators

Terraform Configuration Files

terraform {
  required_providers {
    github = {
      source  = "integrations/github"
      version = ">= 6.7.0"
    }
  }
  required_version = "~> 1.0"

  backend "local" {
    path = "terraform.tfstate"
  }
}

provider "github" {}

resource "github_team" "some_team" {
  name        = "SomeTeam"
  description = "Some cool team"
}

resource "github_repository" "some_repo" {
  name = "some-repo"
  visibility = "private"
}

resource "github_repository_collaborators" "some_repo_collaborators" {
  repository = github_repository.some_repo.name

  team {
    permission = "pull"
    team_id = github_team.some_team.id
  }
}

resource "github_team" "some_security_team" {
  name        = "SomeSecurityTeam"
}

resource "github_organization_role_team" "test-team-role-assignment" {
  team_slug = github_team.some_security_team.slug
  role_id   = "138" # security_manager (predefined)
}

Steps to Reproduce

terraform init
terraform apply
terraform plan

Debug Output

Panic Output

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]

What makes you think that it relates to the org role?

[christianfaucher]

When the drift started occurring, it affected all our repository-related Terraform states across the entire organization. This happened immediately after we assigned an organization role to one of our teams.

To understand the situation, we isolated the behavior and reproduced it with the simplest possible Terraform configuration in a test organization. The drift consistently appears only when an organization-level role is attached to a team. The issue does not occur when using enterprise roles.

Digging a bit deeper, we noticed that the API endpoint used by the provider (/repos/:owner/:repo/teams) returns teams that were granted access via organization roles, but it does not return those coming from enterprise roles. This difference in API behavior seems to explain why the drift appears only in the case of organization roles.

[deiga]

@christianfaucher Thanks for the thorough explanation!

but it does not return those coming from enterprise roles.

Why would this be relevant? In your example at least we're dealing with teams, repos and roles in an Org, right?

[christianfaucher]

but it does not return those coming from enterprise roles.

Why would this be relevant? In your example at least we're dealing with teams, repos and roles in an Org, right?

Exactly, in my example I'm demonstrating everything at the Org level because this is the scenario where the issue occurs.
I only mentioned enterprise teams and roles to highlight that the behavior differs depending on how the access is granted. In our organization we have both cases:

• teams that receive access through organization roles, and
• teams that receive access through enterprise roles.

The API endpoint used by the provider (/repos/:owner/:repo/teams) returns teams that have access via organization roles, but it does not return teams whose access comes from enterprise roles.

[stevehipwell]

@christianfaucher the github_repository_collaborators resource has ignore_team specifically to handle this issue. GitHub doesn't provide a way to filter out the teams that have been added to the repository via the org or enterprise, and calling the org/enterprise endpoints as part of this resource would rapidly burn through the API limits. The provider is behaving as intended.

Short term we could look at adding something like ignore_team_pattern to support dynamically filtering out teams that are named in a consistent way as an improvement on the ignore_team pattern.

Longer term if we move support for caching API requests outside of the individual resource logic we would be able to call the relevant endpoints to lookup the teams which should be ignored directly without the risk of blowing through all of the rate limit allowance.

[christianfaucher]

Thanks for the information. I hadn’t noticed that option. We’ll use it.