GitLab

requests

This adds an optimised way of getting the latest pipeline status for a
list of Commit objects (or just a single one).

Use Commit#notes and Note.for_commit_id when possible to make sure we use all the indexes available to us

also, I refactored the MergeRequest#fetch_ref method to express
the side-effect that this method has.

  MergeRequest#fetch_ref -> MergeRequest#fetch_ref!
  Repository#fetch_source_branch -> Repository#fetch_source_branch!

this will remove the need make N queries (per-note) at the
cost of having to mark notes with an attribute

this opens up the possibility for other special roles for notes

This changes the issue and MR index pages so the pagination system
re-uses the output of the COUNT(*) query used to calculate the number of
rows per state (opened, closed, etc). This removes the need for an
additional COUNT(*) on both pages.

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

I don't know why this happens exactly, but given an upstream and fork repository
from a customer, both of which required GC, resolving conflicts would corrupt
the fork so badly that it couldn't be cloned.

This isn't a perfect fix for that case, because the MR may still need to be
merged manually, but it does ensure that the repository is at least usable.

My best guess is that when we generate the index for the conflict
resolution (which we previously did in the target project), we obtain a
reference to an OID that doesn't exist in the source, even though we already
fetch the refs from the target into the source.

Explicitly setting the source project as the place to get the merge index from
seems to prevent repository corruption in this way.

Fixes https://sentry.gitlap.com/gitlab/gitlabcom/issues/26786/

https://gitlab.com/gitlab-org/gitlab-ce/builds/14070787

Also poll for pipeline changes on:
 - Pipeline table on commit page
 - Pipeline table on merge request page
 - Pipeline table on new merge request page