MR approval rules don't load on MRs from forked projects back to the upstream project
Summary
Reported by a Premium customer with 425 seats - see ZD (internal use only)
When creating an MR from a forked project and setting the target to a branch on the upstream project, the upstream project's merge request approval rules are not loaded.
This contradicts the documentation Merge request approval rules:
Merge requests that target a different project, such as from a fork to the upstream project, use the default approval rules from the target (upstream) project, not the source (fork).
Steps to reproduce
- Create a new project (upstream)
- Create a forked project based on the upstream project.
- On the upstream project, create at least one MR approval rule that targets the
main
branch. - On the forked project, make a change and create a new MR - and set the target to the
main
branch on the upstream project. - Observe that the MR approval rules from the upstream project do not load on the create MR page.
Example Project
N/A
What is the current bug behavior?
When creating an MR from a forked project and setting the target to a branch on the upstream project, the upstream project's merge request approval rules are not loaded.
What is the expected correct behavior?
When creating an MR from a forked project and setting the target to a branch on the upstream project, the upstream project's merge request approval rules should be loaded.
Relevant logs and/or screenshots
Upstream project MR approval rules:
Creating the MR from the fork and pointing the target to the upstream project:
Output of checks
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
@hchouraria has provided a great analysis of the bug below - thank you Harsh!
The bug does appear to do with the branch name we're passing to the endpoint.
This is called with the qualified path to the branch name, notice that it returns just the base rules because it does not recognize the branch passed:
irb(main):011:0> pp Project.find(4).visible_approval_rules(target_branch: 'mercury/apples/sample-ci:main')
[#<ApprovalProjectRule:0x00007f099240abf8
id: 1,
created_at: Wed, 01 Sep 2021 23:31:58.446949000 UTC +00:00,
updated_at: Wed, 01 Sep 2021 23:31:58.446949000 UTC +00:00,
project_id: 4,
approvals_required: 2,
name: "All Members",
rule_type: "any_approver",
scanners:
["sast",
"secret_detection",
"dependency_scanning",
"container_scanning",
"dast",
"coverage_fuzzing",
"api_fuzzing"],
vulnerabilities_allowed: 0,
severity_levels: ["info", "unknown", "low", "medium", "high", "critical"]>]
Next, the call is repeated with the actual branch name, notice that it now additionally return the custom rules available for the branch:
irb(main):012:0> pp Project.find(4).visible_approval_rules(target_branch: 'main')
[#<ApprovalProjectRule:0x00007f0994874430
id: 1,
created_at: Wed, 01 Sep 2021 23:31:58.446949000 UTC +00:00,
updated_at: Wed, 01 Sep 2021 23:31:58.446949000 UTC +00:00,
project_id: 4,
approvals_required: 2,
name: "All Members",
rule_type: "any_approver",
scanners:
["sast",
"secret_detection",
"dependency_scanning",
"container_scanning",
"dast",
"coverage_fuzzing",
"api_fuzzing"],
vulnerabilities_allowed: 0,
severity_levels: ["info", "unknown", "low", "medium", "high", "critical"]>,
#<ApprovalProjectRule:0x00007f0994859ab8
id: 2,
created_at: Wed, 01 Sep 2021 23:32:28.826572000 UTC +00:00,
updated_at: Wed, 01 Sep 2021 23:32:28.826572000 UTC +00:00,
project_id: 4,
approvals_required: 1,
name: "Main Protection",
rule_type: "regular",
scanners:
["sast",
"secret_detection",
"dependency_scanning",
"container_scanning",
"dast",
"coverage_fuzzing",
"api_fuzzing"],
vulnerabilities_allowed: 0,
severity_levels: ["info", "unknown", "low", "medium", "high", "critical"]>]
The API path called here was:
/api/v4/projects/4/approval_settings?target_branch=mercury%2Fapples%2Fsample-ci:main
We're calling the API on the right target project so there appears to be no need to pass a fully qualified branch name path - this needs to be fixed to just carry target_branch=main
in the example above. Perhaps the wider changes in #13574 planned to fix these eventually?
Workarounds
- Change the MR approval rule's target branch to Any branch.