Add ability to opt out of listing branches in github_repository

[k24dizzle]

Related to #892

Affected Resource(s)

Please list the resources as a list, for example:

• github_repository

I started seeing the branches being listed for repos in the terraform plan output, with the introduction of version 4.19.0

Would it be possible to introduce a way to opt out of this behavior (where branches are managed by the github_repository resource)?

There are repos we manage with the github provider that have 100s or even 1000s of branches, so I want to avoid cases where:

• the plan output is unreadable and cluttered with github branches
• it would be unnecessary for us to list every single branch (making hundreds of Github API calls) and store it in the terraform state as we don't even take advantage of this functionality.

[PopBot]

Let me know what I can do to help :)

[jcogilvie]

👍 and a more generalized use case:

I think a shallow option might be useful on github_repository. My org is pinned to provider v4.11 since the additional graph nodes added in v4.12 that sent our build from 15 minutes to over an hour. It's the same phenomenon as this issue, but broader.

[bobtfish]

Came here to report this same problem, since the upgrade we have had to add:

lifecycle {
    ignore_changes = [
      branches
    ]
}

to our code to fix spurious diffs cluttering up the plan output.

We generally only one to control a handful of branches, but allow users to create / push to other branches and having the diff output makes the provider non-useful for auditing any manual changes that have been made.

[PopBot]

@k24dizzle should I look into something in particular?

[jcudit]

lifecycle {
    ignore_changes = [
      branches
    ]
}

this seems like a decent workaround. Interested to learn more if there are other ideas.

[Fleshgrinder]

For what it's worth, this is also forcing us to stay with 4.14.0 for exactly the reasons given above. We also have hundreds of repositories with hundreds of branches that are not being cleaned properly. Having this in the state makes it explode. The lifecycle workaround removes the branch listing from the output, but they still get stored in the state.

I think a shallow option might be useful on github_repository. My org is pinned to provider v4.11 since the additional graph nodes added in v4.12 that sent our build from 15 minutes to over an hour. It's the same phenomenon as this issue, but broader.

We switched to terragrunt because of the extremely slow speed to make changes, but I guess this would help us to speed it up even further.

[k24dizzle]

One idea I had, we could refactor out the branches attribute in github_repository to a new separate github_repository_branches data source.

I think as a matter of organization, branches shouldn't belong to the attributes of github_repository. These fields: https://registry.terraform.io/providers/integrations/github/latest/docs/resources/repository#attributes-reference should be relevant to the repository itself, not other auxiliary resources (like teams, branches, etc.)

Similar to github_repository_pull_requests: https://registry.terraform.io/providers/integrations/github/latest/docs/data-sources/repository_pull_requests, it would be better to create a new data source to contain this information instead.

[danielpops]

lifecycle {
    ignore_changes = [
      branches
    ]
}

this seems like a decent workaround. Interested to learn more if there are other ideas.

It's not really a sufficient workaround IMO, as the branches still show up in the plan when there are any other diffs for the repo resource

[devopsrick]

Are any resources being devoted to this issue? Our github management workspace is exceptionally slow as it crawls information about every branch in every repo resource and repo data source.

[k24dizzle]

I gave a shot to fix this issue here: #1117

Would appreciate any feedback on the best ways to potentially roll this change out.

[github-actions]

👋 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!

[conor-hennessy-axomic]

This is an unresolved issue and so should remain open/active.