Prior to 12.1, rebase status was looked up directly from Gitaly. In
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14417 , a DB
column was added to track the status instead. However, we couldn't stop
looking at the gitaly status immediately, since some rebases may been
running across the upgrade.
Now that we're in 12.3, it is safe to remove the direct-to-gitaly
lookup. This also happens to fix a 500 error that is seen when viewing
an MR for a fork where the source project has been removed.
We still look at the Gitaly status in the service, just in case Gitaly
and Sidekiq get out of sync - I assume this is possible, and it's a
relatively cheap check.
Since we atomically check and set `merge_requests.rebase_jid`, we
should never enqueue two `RebaseWorker` jobs in parallel.
Splits auto-refreshing of MR widget into 2 requests:
- the one which uses etag-caching and invalidates the fields on change
- the one without caching
The idea is to gradually move all the fields to etag-cached endpoint
Today, Pipelines for merge train run on `refs/merge`,
however, this causes a race condition that it can be
overwritten by CheckMergeabilityService.
This patch fixes the problem by generating `refs/train`
for those pipelines.
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.
When a user sets only_allow_merge_if_pipeline_succeeds, also named
as "Pipeline must succeed" project setting, we require the pipeline
to be present.
This solves race condition issues especially with external CI
providers when a build is triggered externally but no pipelines are
created in GitLab yet.
Document that a head pipeline is expected when using "Pipeline
must succeed" setting. Also explain limitations with the use of
only/except where there may not be any jobs created and the merge
request will not be allowed to be merged.
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.
GitLab Bot
Shinya Maeda
Nick Thomas
Igor
George Koltsov
Fabio Pitino
Oswaldo Ferreira