Skip to content

api: Expose merge request reviewers

Rémy Coutable requested to merge api-expose-mr-reviewers into master

What does this MR do and why?

This exposes the current merge request reviewers (i.e. the MergeRequestReviewer records), so that it's possible to know what's the state of a reviewer's review at any time (unreviewed / reviewed), through a new GET /projects/:id/merge_requests/:merge_request_iid/reviewers endpoint. The implementation is very similar to the GET /projects/:id/merge_requests/:merge_request_iid/participants endpoint.

Open questions are:

  • Does the endpoint name makes sense / is acceptable?
  • Do the response payload makes sense?

I couldn't find an issue for this new endpoint, but Contributor Success has a need for it to automate the state management of Community contribution MRs (see discussion at gitlab-com/www-gitlab-com#13718 (comment 1040568752)).

Screenshots or screen recordings

Screen_Shot_2022-07-27_at_18.19.49

How to set up and validate locally

  1. Create a merge request
  2. Visit the GET /projects/:id/merge_requests/:merge_request_iid/reviewers endpoint => [] should be returned
  3. Add the current user as reviewer to the merge request
  4. Visit the GET /projects/:id/merge_requests/:merge_request_iid/reviewers endpoint => a response similar to the above screenshot should be returned
  5. Start and submit a review with the current user
  6. Visit the GET /projects/:id/merge_requests/:merge_request_iid/reviewers endpoint => the response should be the same except that state should now be equal to reviewed
  7. Remove the reviewer from the merge request
  8. Visit the GET /projects/:id/merge_requests/:merge_request_iid/reviewers endpoint => [] should be returned

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Rémy Coutable

Merge request reports