Partially addresses #47424.

repository.can_be_merged? can raise error if diff_head_sha or
target_branch are absent, therefore check those explicitly.

There is still the edge case when 'no commits' changes to 'conflict'
would not trigger notification, which we ignore for now.

Calling can_be_merged? can cause exception (e.g. non-UTF8)
Ignore those by rescueing.

Remove unmergeable_reason as now only conflict is notified

Update spec

"Maintainer" will be freed to be used for #42751

lulalala authored 6 years ago and Mark Chao committed 6 years ago

Old behavior of creating TODO when
“Merge When Pipeline Succeeds” service fails, is generalized to:

Create a TODO whenever MR became unmergeable
(and similar to notification, MR author and merge_user are both applicable)

lulalala authored 6 years ago and Mark Chao committed 6 years ago

Display MR unmergeable reasons

lulalala authored 6 years ago and Mark Chao committed 6 years ago

For notifying via todo or email.

lulalala authored 6 years ago and Mark Chao committed 6 years ago

First, transitions between can_be_merged & cannot_be_merged are removed,
as they are currently blocked in `check_if_can_be_merged`.
`can_be_merge` always returns to `unchecked` first,
before it can transition to `cannot_be_merged` (and vice versa).

We want to avoid repeated notification triggered by repeated transition
between `cannot_be_merged` & `unchecked`.

So we added `cannot_be_merged_recheck` state, similar to `unchecked`,
but as a mean to remember it’s from cannot_be_merged.

See https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18042/#note_65945407

Since `unchecked` and `cannot_be_merged_recheck` both mean
“we are in the middle of checking if it is mergeable”,
quite often we need to see if merge_status is in either one of them,
so `check_state?` is added to achieve this.

Previously, this would issue a query for each unique `diff_refs_or_sha`
passed. This was because we didn't want to load other MR diffs into memory, as
they had some very large columns.

Now they are actually very small, and it's more efficient to just load them all
at once and do the finding in Ruby.

Previously, we kept them all in the cache. We don't need the highlight results
for older diffs - if someone does view that (which is rare), we can do the
highlighting on the fly.

We only allow users that can merge the merge request to push to the
fork.

When a project is not private, and the source branch not protected the
user can now select the option to allow maintainers to push to this
branch

MergeRequest#rebase_in_progress? and MergeRequest#rebase_path were called
twice each time per request. This memoization helps reduce the overall number
of queries.

See https://gitlab.com/gitlab-org/gitlab-ee/-/jobs/51616319 as a failing
job.

Closes gitlab-org/gitlab-ee#4857

On MySQL, at least, `Note#created_at` doesn't seem to store fractional seconds,
while `MergeRequest::Metrics#merged_at` does. This breaks the optimization
assumption that we only need to search for notes created *after* the MR has
been merged.

Unsynchronized system clocks also make this a dangerous assumption to make.

Adding a minute of leeway still optimizes away most notes, but allows both
cases to be handled more gracefully. If the system clocks are more than a
minute out, we'll still be broken, of course.

If we search for notes before the MR was merged, we have to load every commit
that was ever part of the MR, or mentioned in a push. In extreme cases, this can
be tens of thousands of commits to load, but we know they can't revert the merge
commit, because they are from before the MR was merged.

In the (rare) case that we don't have a `merged_at` value for the MR, we can
still search all notes.

This removes all usage of soft removals except for the "pending delete"
system implemented for projects. This in turn simplifies all the query
plans of the models that used soft removals. Since we don't really use
soft removals for anything useful there's no point in keeping it around.

This _does_ mean that hard removals of issues (which only admins can do
if I'm not mistaken) can influence the "iid" values, but that code is
broken to begin with. More on this (and how to fix it) can be found in
https://gitlab.com/gitlab-org/gitlab-ce/issues/31114.

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/37447

When a project uses fast-forward merging strategy user has
to rebase MRs to target branch before it can be merged.
Now user can do rebase in UI by clicking 'Rebase' button
instead of doing rebase locally.

This feature was already present in EE, this is only backport
of the feature to CE. Couple of changes:
* removed rebase license check
* renamed migration (changed timestamp)

Closes #40301

The hook ordering influenced the diffs being generated as these used
values from before the update due to the memoization still being in
place. This commit reorders them and tests against this behaviour.