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_ee only, not the create params, so POST /projects ignores it. Reviewer auto-assignment is configured against an existing project.
  • License gated — both the write (in filter_attributes_using_license!) and the read (entity if: condition) go through reviewer_auto_assignment_available?, which checks the code_owners licensed 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

  1. On a project with the code_owners licensed feature available:
    curl --request PUT \
      --header "PRIVATE-TOKEN: <your_access_token>" \
      --url "https://gitlab.example.com/api/v4/projects/<id>" \
      --data "reviewer_assignment_strategy=code_owners"
    The response includes "reviewer_assignment_strategy": "code_owners".
  2. Without the code_owners licensed feature, the same request leaves the value unchanged and the field is absent from the response.

References

A follow-up MR will expose the same setting through GraphQL.

Edited by Marc Shaw

Merge request reports

Loading
Loading