Loading
Expose reviewer_assignment_strategy in project update API
What does this MR do and why?
Exposes the reviewer_assignment_strategy project setting through the REST API so
it can be configured and read programmatically. Until now it could only be changed
through the project settings UI (Settings → Merge requests → Automatic reviewer
assignment), which made bulk/programmatic configuration impossible.
The setting is added to PUT /projects/:id and to the project entity (read).
Scope & gating
- Edit-only — the parameter is added to
optional_update_params_eeonly, not the create params, soPOST /projectsignores it. Reviewer auto-assignment is configured against an existing project. - License gated — both the write (in
filter_attributes_using_license!) and the read (entityif:condition) go throughreviewer_auto_assignment_available?, which checks thecode_ownerslicensed feature. When it is unavailable the parameter is ignored and the field is not exposed. Automatic Code Owners reviewer assignment is now generally available, so there is no feature-flag gate.
Accepted values mirror the model enum: disabled, code_owners, dap_powered.
How to test
- On a project with the
code_ownerslicensed feature available:The response includescurl --request PUT \ --header "PRIVATE-TOKEN: <your_access_token>" \ --url "https://gitlab.example.com/api/v4/projects/<id>" \ --data "reviewer_assignment_strategy=code_owners""reviewer_assignment_strategy": "code_owners". - Without the
code_ownerslicensed feature, the same request leaves the value unchanged and the field is absent from the response.
References
- Issue: #601621 (closed)
- Epic: &20708 (closed)
- Related fix MR (context): !237226 (merged)
A follow-up MR will expose the same setting through GraphQL.
Edited by Marc Shaw