When a user updates a merge request coming from a fork, they should
not be able to set `force_remove_source_branch` if they cannot push
code to the source project.
Otherwise developers of the target project could remove the source
branch of the source project by setting this flag through the API.
Because we don't have any destroy callbacks (or other logic
triggered on event destroy), there is no reason for deleting events
inefficiently one by one, instead we can use :delete_all.
These are the structural changes for supporting the EE feature of moving
"code_owner_approval_required" state from existing on a project to being
on the protected branches individually, allowing for CODEOWNER
validation on push events.
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
Concurrent calls to UserMergeToRef RPC updating a single ref
can lead to an opaque fail that is being rescued at Gitaly.
So this commit adds an exclusive lease to the mergeability
check process with the key as the current MR ID.
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.
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.
Starting with Rails 5, belongs_to now adds a presence validation to the
association, and so as of shoulda-matchers 4.0.0 the belong_to matcher
follows suit and tests that this validation is there by setting the
association to nil and asserting that there are validation errors. This
exposed an error with the `validate_branches` method: we need to check
the source and target project exist.
Prevents refspec as branch name, which would bypass branch protection
when used in conjunction with rebase.
HEAD seems to be a special case with lots of occurrence,
so it is considered valid for now.
Another special case is `refs/head/*`, which can be imported.
Due to the nature of pipelines for merge requests, deployments.ref can
be a merge request ref instead of a branch name.
We support the environment auto-stop hook for this case
Adds the groundwork needed in order to persist multi-line suggestions,
while providing the parsing strategy which will be reused for the
**Preview** as well.
This commit updates the pipeline block that appears on the merge request
page to include information that will be exposed by the API as part of
the post-merge pipeline feature.
Make it sane
Include merge ref head
Fix union
Improve a bit
Add spec
remove
add spec
Add changelog
fix coding offence
Apply suggestion to spec/models/merge_request_spec.rb
ok
ok
Fix
Fix spec
Fix spec
fix
Simplify the things
Memoize
OK
a
By preloading associations and batching issuable metadata lookups,
we can significantly cut the number of SQL queries needed to load
the Todos API endpoint.
On GitLab.com, my own tests showed my user's SQL queries went
from 365 to under 60 SQL queries.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/40378
Adds the ground work for writing into
the merge ref refs/merge-requests/:iid/merge the
merge result between source and target branches of
a MR, without further side-effects such as
mailing, MR updates and target branch changes.
Add project when creating milestone in specs
We validate milestone is from the same
project/parent group as issuable ->
we need to set project in specs correctly
Improve methods names and specs organization
GitLab Bot
Yorick Peterse
Bob Van Landuyt
Can Eldem
Jan Provaznik
Kerri Miller
Shinya Maeda
Nick Thomas
Igor
Eugenia Grieff
Oswaldo Ferreira
Andreas Brandl
Robert Speicher
George Koltsov
Dmitriy Zaporozhets
Mark Chao
Fabio Pitino
Douwe Maan
Yorick Peterse
GitLab Release Tools Bot
Stan Hu
Jasper Maes
Matija Čupić
Heinrich Lee Yu
Sean McGivern
Douglas Barbosa Alexandre
Francisco Javier López
Kamil Trzciński
Felipe Artur
Nathan Friend
Hiroyuki Sato
John Jarvis
Olivier Gonzalez
Jarka Košanová