terraform-provider-github: 3.1.0 has breaking changes which are not identified in changelog

😞 apologies on this one.

Please either revert this change or release a 4.0.0 with actual updated documentation.

I am inclined to revert the change and cut a new v3.x release.

Can I get some 👍 👎 feedback on this approach?

Solid feedback everyone ❤️ . Aiming to cut v4.0.0 with valid release notes / docs this week.

I’m also inclined to add a github_branch_protection_v3 resource for anyone that wants to stay current with other changes but hang in with the previous REST implementation and feature set. Hoping this provides a stable option as we work through issues with the GraphQL implementation.

☝️ reverts the changes that removed repository and branch. The new fields are now computed so we can keep the same implementation behind the v3 configuration interface. Breaking changes are now queued for the v4 release, hopefully around end of year.

I think this is a good compromise, but let me know if I have overlooked anything. If this plan does not work, I am still open to cutting a new major release or a more aggressive revert that re-instates the old implementation.

👎 / 👍 what do you all think?

repository_id = github_repository.foo.node_id was the key for me doing the upgrade. I was able to update branch -> pattern without any changes.

I don’t think node_id is documented that I could find, but it appears to be related to the upgrade to the v4 (graphql) api.

Being able to declare branch protection rules against branch names with wildcards has been a long awaited feature for me and my team, and it requires the GraphQL API. I started using the github provider for my project when v3.1.0 came out because I wanted to use terraform, but couldn’t until this was supported.

If at all possible, it would be nice if this feature was added back sooner than the end of the year.

When you guys release v4, would it be possible to do something like

schema.Schema{
    "repository": { ConflictsWith: []string{"repository_id"} }
    "repository_id": { ConflictsWith: []string{"repository"} }
}

Because sometimes I don’t have a resource "github_repo" "foo" handy and don’t really want the extra data lookup

I think we should just cut a 4.0.0 release with valid release notes/documentation.

End of the day version numbers are free.

@jcudit Sorry, but there’s no longer an option to revert in my book - many have built against v3.1 already! You made a mistake - we all do, but 3 weeks have passed since then, and it’s too late to revert.

@jcudit Not to add to your plate, but we’re still waiting for the org-level secrets! The feature was released half a year ago and is still unsupported.

We use a for_each loop to create our repositories, and a separate for_each loop to set up branch protection for 1 or more branches per repository. Being able to use the id (which was just the name) was nice & simple, but having to retrieve the node_id from the repository resource and apply that into the branch_protection resource looks like it’s a pain.

I’d tend to agree, I think there is a need to fail forward here. Not only is wildcard use in branch protection rules super common and something many of us using this provider have been waiting ages for, but many of us are using 3.1.0 with some amount of success and getting “stuck” on 3.1.0 or having to deal with state rm’ing and reimporting affected resources on another version of the provider is kind of a nightmare.