Implement the "protected branches" API endpoint

[gitlabform]

Implement the "protected branches" API endpoint

[gdubicki]

I think that you misunderstood me: it's already implemented in gitlabform and I did it was when this API was not yet deprecated. :)

[gdubicki]

Sadly I don’t have time to develop this myself currently, but we are open to accepting PRs with this.

[therealgambo]

@gsemet - Ive implemented protected tag functionality in #39

[gdubicki]

gitlabform has support for older, now deprecated API for protecting branches, see https://github.com/egnyte/gitlabform/blob/master/config.yml#L90 .

[born4new]

If it's deprecated, I don't think it's a great idea for us to start using it :).

[gdubicki]

Note to self: when implementing this we should take #10 into account.

[born4new]

Any news on that one?

Also, I now realize that I haven't replied to your comment:

I think that you misunderstood me: it's already implemented in gitlabform and I did it was when this API was not yet deprecated. :)

Point being that we would like to be able to configure protected branches in a non-deprecated way according to GitLab :).

[gsemet]

"Protected tag" as well?

[gdubicki]

Note to self: we can implement this feature as:

• replacement for the current way of managing branch protection, including different syntax - this would require major version uptick,
• adding new way next to the old way with making the old one use the new API under the hood.

Of course the 2nd is more user-friendly but because we have too little maintainers of this app I would prefer the 1st as it requires less maintenance.

We can prevent the app from running ONLY IF user is using branch protection config and does not declare the config to be compatible with GitLabForm v. 2.*.

After we implement new approvers API in #68 we will probably have to do the same.

Ideally we should do both of these changes together to have only a single major version uptick here.

While creating v.2 we can think about more config syntax improvements. Let's discuss them in a separate issue.