Setting members_can_fork_private_repositories resets organisational fork policy

[fatbasstard]

We're now using the github_organization_settings to configure some organisational settings (instead of "manual") and we noticed that settings members_can_fork_private_repositories works in unexpected ways with the organisational settings:

We had forking set to User accounts, imported the github_organization_settings resource (where members_can_fork_private_repositories apparantly is set to True and not TF changes this to the "Default" Organisations within this enterprise.

This is quite unexpected behaviour, and after reading up other issues decided to remove this setting from the resource entirely. When removing it TF actually said it would change the setting (update members_can_fork_private_repositories : true change to false). But the setting is now kept intact.

So:

• Organisation settings and Forking looks "off" (could be related to Enterprise)
• Is there a resource to change the forking policy of an (enterprise) organisation?

Related links:

• [feat]: Enterprise Settings #1199
• github_organization_settings errors for forking policy has been set by enterprise administrators #1333
• Type: Bug | Fixes validation error when forking policy has been set by enterprise administrators. #1362

[kfcampbell]

I'm sorry, I'm not quite sure what you mean by:

This is quite unexpected behaviour, and after reading up other issues decided to remove this setting from the resource entirely. When removing it TF actually said it would change the setting (update members_can_fork_private_repositories : true change to false). But the setting is now kept intact.

Would you mind rephrasing this for me a little differently and I can try to help troubleshoot?

[fatbasstard]

Hi @kfcampbell,

Organisation setting in the GUI:

Applying Terraform with the following (which gives no changes):

resource "github_organization_settings" "connectedbrewery" {
...
  members_can_fork_private_repositories = true
...
}

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

[fatbasstard]

Any update on this issue?

[tpham-drw]

We use github_organization_settings with members_can_fork_private_repositories but are not seeing the sub-setting for the fork destination being reset by Terraform I spoke too soon - if the TF apply touches github_organization_settings, even though the change is not shown in the plan, it will reset the settings.

It would be good to be able to set this in TF instead of manually though.

[minsis]

+1 on this. Its less about being a bug and more about needing to add the feature of being able to select which rule to apply for forking private repos.

[minsis]

Also wanted to mention I took a quick look at the GitHub API and I don't see any field that actually sets the forking rule when enabling members_can_fork_private_repositories. So, this could end up being a limitation on the GitHub API.
https://docs.github.com/en/rest/orgs/orgs?apiVersion=2022-11-28#update-an-organization

I also tested some other scenarios directly on the API and here is what I've found so far:

• Submitting only members_can_fork_private_repositories=false results expected behavior of disabling said property
• Submitting only members_can_fork_private_repositories=true when previous setting was false will enable said property with the first option selected.
• Submitting only members_can_fork_private_repositories=true when already set to true will reset the property back to the first option, regardless of what it was previously.
• Submitting any other property by itself (I used default_repository_permission=write) while members_can_fork_private_repositories=true AND selected any other option will not change the options selected for members_can_fork_private_repositories
• Submitting any other property (I used default_repository_permission=write) AND members_can_fork_private_repositories=true will reset the property back to the first option, regardless of what it was previously.

So, without really digging into the code (because I suck at go), my assumption is that the provider is redundantly submitting members_can_fork_private_repositories: true regardless of changes to said property defined in the template.

I guess maybe the work around might be to exclude submitting this property if its already set to true, and only submit if it is changing from false to true.

Also, maybe creating a feature request or something to GitHub to update the management of this property, not sure how that is actually done. I am an enterprise customer so if I can help make this request, I'd be happy to.

[minsis]

Have any of the contributors been able to investigate this issue?