-
Notifications
You must be signed in to change notification settings - Fork 68
Open
Labels
area/gitlabGitLab-forge relatedGitLab-forge relatedcomplexity/single-taskRegular task; should be done within daysRegular task; should be done within dayskind/bugAn unexpected problem or behaviorAn unexpected problem or behavior
Description
What happened? What is the problem?
GitlabProject.who_can_merge_pr() is not correct… It accounts only for the default settings which can be overriden as GitLab allows setting custom rules as part of their branch protection, i.e.,:
- maintainers, or
- maintainers and developers, or
- specific deploy keys (for push and merge), or even
- specific users and groups (when the repository is under paid GitLab plan).
What did you expect to happen?
Correct subset of users/groups that are allowed to merge the MRs. Though I'm not sure what privileges would the token require to acquire this kind of information via the REST API.
Example URL(s)
-
Code:
ogr/ogr/services/gitlab/project.py
Lines 182 to 191 in d8e61f4
def who_can_merge_pr(self) -> set[str]: return set( self._get_collaborators_with_given_access( access_levels=[ gitlab.const.DEVELOPER_ACCESS, gitlab.const.MAINTAINER_ACCESS, gitlab.const.OWNER_ACCESS, ], ), ) -
REST API docs: https://docs.gitlab.com/api/protected_branches/
Steps to reproduce
Workaround
- There is an existing workaround that can be used until this issue is fixed.
Participation
- I am willing to submit a pull request for this issue. (Packit team is happy to help!)
Notes
Came up during the onboarding discussions with @modehnal
Metadata
Metadata
Assignees
Labels
area/gitlabGitLab-forge relatedGitLab-forge relatedcomplexity/single-taskRegular task; should be done within daysRegular task; should be done within dayskind/bugAn unexpected problem or behaviorAn unexpected problem or behavior
Type
Projects
Status
backlog