| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
This brings the rspec-core version in line with the Gitaly changes
and introduces Rails 5.1/5.2 improvements.
Full CHANGELOG:
https://github.com/rspec/rspec-rails/blob/master/Changelog.md
|
| | |
|
| |
|
|
|
|
| |
When recheck flag is true, we make sure the merge-ref
is indeed outdated. If it is, we update it along
the merge status.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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 introduces payload to the ServiceResponse with
the merge ref HEAD commit data
|
|
|
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.
|
