Manage group-level merge request approval settings via API
Why are we doing this work
Allow group owner to view and update group-level merge request approval setting via API
Non-functional requirements
-
Feature flag: group_merge_request_approval_settings_feature_flag
-
Performance: -
Testing:
⚙ Implementation plan
For a Project A
with settings a
and owned by a Namespace hierarchy of B1
, B2
, Bn
with corresponding setting b1
, b2
, bn
. We would like to determine the following at Project A:
- What is the effective setting of
a
when inheritance is enforced (more likely the default) - What is the effective setting of
a
when inheritance is not enforced
The rough plan I have in mind:
- Calculate the namespace hierarchy
- Retrieve all settings of these namespaces
- Retrieve project settings
- Pass these settings through a rule engine -> effective Project
A
settings
Zoom in a little bit more at the SQL-query level:
- 1 recursive CTE query to
namespaces
to retrieve all ancestor ids (e.g.self_and_ancestors_ids
) - 1 query to
merge_request_approval_settings
to get all namespace settings -
1 query to
merge_request_approval_settings
to get ProjectA
settings (currently this is underprojects
table)
👣 Tasks
-
database Introduce a new table group_merge_request_approval_settings
and associations withnamespaces
-
backend Add new service ee/app/services/merge_request_approval_settings/update_service.rb
to update approval setting -
backend Create API for Group MR approval settings ( GET
andPUT
)
Alternative DB Designs
- yellow: existing
- pink: this issue
- green: future iterations
Approach A
Approach B
Approach C
Approach D
Advantages
- Reuse the existing tables
- All the backend fabrication are already built with batteries
Disadvantages
- Similar to Approach A (aka. this could lead to duplicated logic in models) but can be extracted to shared modules.
From what I can see, we have to issue two separate queries to retrieve project and namespace settings anyway, whether we have them in the same table with different id fields or separate tables Approach A
and B
would not make much difference in terms of the number of queries.
Edited by Tan Le