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

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26248 added
support for deduplicating FindCommit requests using Gitaly ref name
caching. However, not all endpoints were covered, and in one case the
Gitaly wrapper wasn't actually surrounding the serialization step. We
can safely cache ref names between FindCommit calls for #index and #show
endpoints for merge requests and pipelines. This can significantly
reduce the number of FindCommit requests.

For a given merge request, it's quite common to see duplicate FindCommit
Gitaly requests because the Gitaly CommitService caches the request by
the commit SHA, not by the ref name. However, most of the duplicate
requests use the ref name, so the cache is never actually used in
practice. This leads to unnecessary requests that slow performance.

This commit allows certain callers to bypass the ref name to
OID conversion in the cache. We don't do this by default because it's
possible the tip of the branch changes during the commit, which
would cause the caller to get stale data.

This commit also forces the Ci::Pipeline to use the full ref name
so that caching can work for merge requests.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/57083

Phil Hughes authored 6 years ago and Mark Chao committed 6 years ago

The user can also toggle between the diff changes and
the full file diff.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/19054

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/57403

In order to have an accurate date about the last activity of a User
we need to update the last_activity_on field when the User is visiting
some basic pages of GitLab like pages related to Dashboards, Projects,
Issues and Merge Requests

In order to let users' sorting preferences transfer between devices, we
save the preference for issues and MRs (one preference for issues, one
for MRs) in the backend inside the UserPreference object

Signed-off-by: Rémy Coutable <remy@rymai.me>

This commit handles note diffs caching, which considerably improves
the performance on merge requests with lots of comments.
Important to note that the caching approach taken here is different
from `Gitlab::Diff::HighlightCache`. We do not reset the whole cache
when a new push is sent or anything else. That's because discussions
diffs are persisted and do not change.

Akos Gyimesi authored 7 years ago and Nick Thomas committed 6 years ago

Also, the error message became shorter.

Move access checks to their own method so they can be overridden, and
port an EE-only method to exist in CE too, with an EE-specific override.