Igor Drozdov authored 5 years ago and Mayra Cabrera committed 5 years ago

- Extract MR fields for notes into a separate serializer
- Check if pipelines are empty via count

Sorting preference functionality has been extracted
from `IssuableCollections` to a new `SortingPreference`
concern in order to reuse this functionality in projects
(and groups in the future).

- Use set_pipeline_variables to filter for visible pipelines
- Mimic response of nonexistent pipeline if not found
- Provide set_pipeline_variables as a before_filter for other actions

MergeRequest#all_pipelines fetches Ci::Pipeline records from the source
project, so we should specifically check that project for permissions.
This was already happening for intra-project merge requests, but in the
event that the target and source projects both have private builds, we
should ensure that the project permissions are respected.

This MR introduces tracking of the `rebase_jid` for merge requests. As
with `merge_ongoing?`, `rebase_in_progress?` will now return true if a
rebase is proceeding in sidekiq.

After one release, we should remove the Gitaly-based lookup of rebases.
It is much better to track this kind of thing via the database.

This commits extracts /merge_requests/1.json?serializer=widget
Into a separate /merge_requests/1/widget.json endpoint
This will allow to use caching for this request

This eliminates many potential duplicate FindCommit RPCs for the same
ref, which often occurs in the RelativeLinkFilter#current_commit call.
On the GitLab 12.0 release post, for example, this would save close to
400 RPC calls.

This couples the code that transitions the `MergeRequest#merge_status`
and refs/merge-requests/:iid/merge ref update.

In general, instead of directly telling `MergeToRefService` to update
the merge ref, we should rely on `MergeabilityCheckService` to keep
both the merge status and merge ref synced. Now, if the merge_status is
`can_be_merged` it means the merge-ref is also updated to the latest.

We've also updated the logic to be more systematic and less user-based.

Currently, merge options is updated on #execute method,
however, we should have #update interface to make it explicit.

We have one auto merge strategy today - Merge When Pipeline
Succeeds.

In order to add more strategies for Merge Train feature,
we abstract the architecture to be more extensible.

Removed arguments

Fix spec

This couples the code that transitions the `MergeRequest#merge_status`
and refs/merge-requests/:iid/merge ref update.

In general, instead of directly telling `MergeToRefService` to update
the merge ref, we should rely on `MergeabilityCheckService` to keep
both the merge status and merge ref synced. Now, if the merge_status is
`can_be_merged` it means the merge-ref is also updated to the latest.

We've also updated the logic to be more systematic and less user-based.

This backports the changes from
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10452