resource/gitlab_project: fix waiting for default branch protection during creation

[timofurrer]

This patch fixes waiting for the protection on the default branch in a
scenario where the project is in a group namespace which has the default
branch protection disabled.

NOTE: I've made some assumption that this can only happen for the
projects in group namespaces (e.g. project in a user namespace can't
turn the default branch protection off) and that this information about
the disabled default branch protection can always be read from the group
the project is directly assigned to.

Closes #906
Caused by #862

/cc @PatrickRice-KSC @armsnyder as you can read above I've made some assumptions. Can any of you confirm these?

[RicePatrick]

@timofurrer - I tested out a couple scenarios on the GitLab API, and as far as I can tell the default_branch_protection will always come back from the API (even if not explicitly set on the "create" or "update" calls), so I think your assumption is valid.

In the interests of defensive coding for future proofing, would we want to assume a value of 2 (fully protected) if the value is not returned from the API? That's the default value set if nothing is specified in the create/update requests.

[timofurrer]

@PatrickRice-KSC

In the interests of defensive coding for future proofing, would we want to assume a value of 2 (fully protected) if the value is not returned from the API?

What do you mean by "not returned from the API?" ? From the client.Groups.GetGroup() call? I think at the moment we kinda do that if the Namespace.Kind is not group. If GetGroup() fails though I think that should be a hard failure and we shouldn't assume anything.

[RicePatrick]

@timofurrer - Sorry, what I meant is if we get a valid response from client.Groups.GetGroup() but where the default_branch_protection is not returned. Which would result in a nil value from the group.DefaultBranchProtection attribute.

I'm talking myself out of it though, because that would cause the branch to then trigger the WaitForState loop, which is exactly the behavior we'd want if it was falling back to the default. Nevermind 😄

[armsnyder]

Thanks for the test! I agree with your assumptions. I did not check what happens if you have a project within a subgroup of another group, but I would assume the default branch protection settings does not cascade.

[github-actions]

This functionality has been released in v3.11.1 of the Terraform GitLab Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue. Thank you!