Do not reset approvals if rebase is performed
Problem to Solve
Currently merge requests have a binary setting that removes all approvals when commits are added to the source branch
. When this setting is enabled, trivial changes such as rebasing, updates to the target branch or others that the approvals are reset.
Resetting the approvals forces authors to get approvals again, even when functionally nothing has changed in the proposed code change.
Additional Details
Conditions which reset approvals:
- merging main to feature branch (
git merge main
) - https://gitlab.com/phikai/author-approval-test/-/merge_requests/2 -
git rebase main
with a then pull (merge) and then push - https://gitlab.com/phikai/author-approval-test/-/merge_requests/3 -
git rebase main
with a force push and no pull - https://gitlab.com/phikai/author-approval-test/-/merge_requests/4
Proposal
GitLab should not reset approvals for rebases which do not change the content of the merge request.
Availability & Testing
Unit tests to be added for the above scenarios if possible. Manual verification or additional E2E test of the above scenarios otherwise.
The E2E tests currently cover the rebase workflow when files are added in rebase_merge_request_spec.rb
which should be executed for regression testing purposes.