support default_branch_protection on group

[domcyrus]

Support using default_branch_protection on group. This is implementing one part of #667

It will need a newer dependency of the "github.com/xanzy/go-gitlab" package. Currently only using github.com/xanzy/[email protected] (master) as the change of the needed default_branch_protection on group is only in master.

[domcyrus]

I've updated the PR to use go-gitlab 0.50.4 which does what #713 also tries but including the needed api changes.

[domcyrus]

Updated PR all tests run successfully.

[switchboardOp]

I'd love to see this merged now that the upstream dependency is released. Default branch protection is causing some issues for me. I was halfway through my own implementation when I found this PR. looks good @domcyrus!

[willianpaixao]

@domcyrus would you mind updating the documentation of the underlying resources as well?

[domcyrus]

@willianpaixao I added the missing documentation and also added unit tests.

[domcyrus]

Is there anything else needed?

[willianpaixao]

@domcyrus thanks! LGTM.

[mkjmdski]

Hi @domcyrus. The newest go-gitlab is already in master you should take it's go mod files and this branch should be good to go.

[domcyrus]

@mkjmdski updated with upstream master.

[mkjmdski]

@roidelapluie could you please enable pipeline in here?

[roidelapluie]

Thanks!

[QuingKhaos]

As a note: it could have supported string values like visibility_level which are translated internally to the int access levels to be consistent..

[roidelapluie]

thanks for your feedback, but I do not understand it. visibility_level is never translated to an int.

[roidelapluie]

terraform-provider-gitlab $ ack PrivateVisibility
gitlab/util_test.go
46:                     Level:  gitlab.PrivateVisibility,

gitlab/util.go
80:             "private":  gitlab.PrivateVisibility,

vendor/github.com/xanzy/go-gitlab/types.go
488:    PrivateVisibility  VisibilityValue = "private"

[roidelapluie]

I think I now understand what you mean. In terraform, the best practice is to stick to the remote API as close as possible. If the gitlab API asks for an integer, I think we should not invent our own values.

[QuingKhaos]

In terraform, the best practice is to stick to the remote API as close as possible.
I may agree.

If the gitlab API asks for an integer, I think we should not invent our own values.

It's already done with the access control level values (maintainer instead of 40) - sorry, confused them with the visibility level. Maybe not directly in the provider, but through the Go SDK. In this case I would prefer consistency with the other values and don't have to guess what does that random number mean in the terraform manifests :)