Your review queue

GitLab answers "what is waiting on my review" for a whole instance in one query, so labdash never walks your projects one at a time. The queue is the first group on Home and it is there the moment you log in.

review-queue
Twelve merge requests from eight projects, none of which you had to name.

What you see

One query covers every project on the instance, including the ones you had forgotten you have access to. It returns in about 4.6 seconds on gitlab.com and costs 37 of the 250 complexity points GitLab allows a request.

Three columns decide whether a row is yours to act on:

  • approvals. 2/2 means it has what it needs. 0/1 means it is still waiting.
  • CI. The head pipeline's status, returned with the merge request rather than fetched separately.
  • BLOCKER. Why it cannot merge, in words. ci failed and conflicts belong to the author, so the row can rule itself out without being opened.

What you can do

KeyActionKeyAction
j kmovevapprove or unapprove
Enterfocus the previewmmerge
oopen in the browserccomment
Ycopy the URLCcheck out the branch
/filter the loaded rowsrrefresh this section

Narrowing the queue

One filter is worth adding: press f and add draft:false. A draft merge request with you on the reviewer list is a work in progress that names you, not a review request.

The same question narrows to a group or a single project, and stays one query. Press b, Enter on platform, then f and review:requested. Press P and it is a tab.

review:unreviewed separates the merge requests you have not looked at from the ones you looked at and sent back. GitLab's own substatus wording appears on the row either way.

The two sibling groups

Same table, different relationship to you. Both are groups on Home:

  • Your merge requests, meaning what you authored or were assigned.
  • Returned to you, meaning reviewers responded and it is your move again.

The empty state

review-queue-empty
An empty state restates the query behind it, so an empty list never reads as a wrong filter.