[go: up one dir, main page]
Skip to content

Protected Branch API Patch request does not update properly

Summary

The Update a protected branch endpoint seems to be broken and allows user to set invalid conditions. For example a user is able to set allowed_to_push to the following values at the same time by issuing a sequence of PATCH requests.

  • Developers + Maintainers
  • Maintainers
  • No One

This is not consistent with how we allow updates in the UI. If No One is set, the other options are automatically removed. From what we observe it looks like the issue happens if the id is not set for the allowed_to_push attribute.

Steps to reproduce

  • Create a new project.
  • Create a branch protection using the POST endpoint with access_level set to 30.
curl --request POST \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.com/api/v4/projects/71138989/protected_branches?name=demo-branch&push_access_level=30"
  • Update the branch protection using the PATCH endpoint with access_level set to 40 
curl --header 'Content-Type: application/json' --request PATCH \
  --data '{"allowed_to_push": [{"access_level": 40}]}' \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.com/api/v4/projects/71138989/protected_branches/demo-branch"
  • Issue another PATCH request.
curl --header 'Content-Type: application/json' --request PATCH \
  --data '{"allowed_to_push": [{"access_level": 0}]}' \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.com/api/v4/projects/71138989/protected_branches/demo-branch"
  • Observe that all options are ticked.

Screenshot_2025-06-26_at_10.43.21_AM

Example Project

https://gitlab.com/kballon-bug-report/zd636858_protected_branch_api_patch/-/settings/repository#js-protected-branches-settings

What is the current bug behavior?

Multiple settings are set.

What is the expected correct behavior?

While multiple settings should be allowed, it should not mix No One with other options.

Relevant logs and/or screenshots

Output of checks

This bug happens on GitLab.com

Results of GitLab environment info

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.

Edited by 🤖 GitLab Bot 🤖