Protecting a branch via the API overwrites web UI push/merge permissions incorrectly
Summary
The branches API allows branches to be listed, created, deleted, protected and unprotected via API calls. Unfortunately, the functionality for protecting branches over the API is not as sophisticated as that of the web UI. Simply, via the API, it's only possible to configure whether users of role Developer
can push/merge to protected branches, while via the Web UI it's possible to configure whether No-one
, Masters
or Masters + Developers
can push or merge respectively.
The bug is that if you've set up that No-one
should be able to push to a protected branch via the web UI, then attempt to configure the branch protection via the API, setting developers_can_push
to false, it'll turn ON push permissions for Masters
. Same thing for merge permissions obviously. This means that branch protection cannot be reliably configured via the API for users who desire No one
to have push access to protected branches.
This is present in both v3 and v4 versions of the API.
Steps to reproduce
- Create a new protected branch via the web UI. Set push permissions to
No one
. - Attempt to protect the branch via the API call. Set
developers_can_push
tofalse
. - The push permission setting is now
Masters
.
What is the current bug behavior?
Setting developers_can_push
to false
sets Masters
to push permission on protected branches.
What is the expected correct behavior?
Ideally I would like the same granularity in the API as there is over the web UI, but even without that,
setting developers_can_push
to false
should NOT set the push permissions to Masters
.
Output of checks
This bug happened on a githost.io instance running Gitlab 9.0.