Age | Commit message (Collapse) | Author |
|
Automatically update MR merge-ref along merge status
Closes #58495
See merge request gitlab-org/gitlab-ce!28513
|
|
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 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.
|
|
Refactor
|
|
The new two-step Gitaly `Rebase` RPC yields the rebase commit SHA to the
client before proceeding with the rebase.
This avoids an issue where the rebase commit SHA was returned when the
RPC had fully completed, and in some cases this would be after the Rails
`post_receive` worker services had already run. In these situations,
the merge request did not yet have its rebase_commit_sha attribute set
introducing the possibility for bugs (such as previous approvals being
reset).
https://gitlab.com/gitlab-org/gitlab-ee/issues/5966
|
|
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
|
|
Users attempting to set merge requests to `remove_source_branch` to
`false` would encounter an Error 500 because the UpdateService and API
checked `present?`, which would always return `false`. We now just
use `has_key?` to decide whether the parameter is present.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/60530
|
|
- Externalize strings in milestones_helper
- Externalize strings in app/services
- Update PO file
|
|
With multiple MR assignees, `merge_request.assignee_id` is always nil,
and `merge_request.assignee_ids` isn't in `merge_request.attributes`.
So the existing code doesn't set assignees in the created MR.
This fix gets all the tests passing, but we should also check that no
other associations in the MergeRequest need similar fixups.
|
|
Update comments about N + 1 Gitaly calls
See merge request gitlab-org/gitlab-ce!27178
|
|
To make sure all known issues are linked to the correct epic, I've gone
through the code base, and updated the comments where required.
|
|
[Backport] Support multiple assignees for merge requests
See merge request gitlab-org/gitlab-ce!27089
|
|
Git push options to create a merge request, set target_branch and set merge when pipeline succeeds
Closes #53198 and #43263
See merge request gitlab-org/gitlab-ce!26752
|
|
This will ensure that now and in the future, PushOptionsHandlerService
will not cause the post_receive API endpoint from running other code if
something causes an unknown exception.
|
|
Exceptions are no longer raised, instead all errors encountered are
added to the errors property.
MergeRequests::BuildService is used to generate attributes of a new
merge request.
Code moved from Api::Internal to Api::Helpers::InternalHelpers.
|
|
MergeRequests::PushOptionsHandlerService has been updated to allow
creating and updating merge requests with the
`merge_when_pipeline_succeeds` set using git push options.
To create a new merge request and set it to merge when the pipeline
succeeds:
git push -u origin -o merge_request.create \
-o merge_request.merge_when_pipeline_succeeds
To update an existing merge request and set it to merge when the
pipeline succeeds:
git push -u origin -o merge_request.merge_when_pipeline_succeeds
Issue https://gitlab.com/gitlab-org/gitlab-ce/issues/53198
|
|
Backports https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10161
(code out of ee/ folder).
|
|
To create a new merge request:
git push -u origin -o merge_request.create
To create a new merge request setting target branch:
git push -u origin -o merge_request.create \
-o merge_request.target=123
To update an existing merge request with a new target branch:
git push -u origin -o merge_request.target=123
A new Gitlab::PushOptions class handles parsing and validating the push
options array. This can be the start of the standard of GitLab accepting
push options that follow namespacing rules. Rules are discussed in issue
https://gitlab.com/gitlab-org/gitlab-ce/issues/43263.
E.g. these push options:
-o merge_request.create -o merge_request.target=123
Become parsed as:
{
merge_request: {
create: true,
target: '123',
}
}
And are fetched with the class via:
push_options.get(:merge_request)
push_options.get(:merge_request, :create)
push_options.get(:merge_request, :target)
A new MergeRequests::PushOptionsHandlerService takes the `merge_request`
namespaced push options and handles creating and updating
merge requests.
Any errors encountered are passed to the existing `output` Hash in
Api::Internal's `post_receive` endpoint, and passed to gitlab-shell
where they're output to the user.
Issue https://gitlab.com/gitlab-org/gitlab-ce/issues/43263
|
|
Currently, pipelines for merge requests are triggered when source or
target branch is updated. However, we should create only when source
branch is updated, because it runs unexpected pipelines.
|
|
MWPSService currently uses the old pipeline lookup method. It searches
related merge requests with pipeline.ref, however, this doesn't work
for attached/detached merge request pipelines.
|
|
Backport changes to CE
|
|
and add spec
Add changelog
ok
ok
|
|
Use merge request HEAD ref for detached merge request pipelines
Closes #58454
See merge request gitlab-org/gitlab-ce!25504
|
|
By using `refs/merge-requests/:iid/head`
ok
ok
Improve naming nicely
Add nice tests
add nice tests
fix some more
revert
|
|
|
|
Allow external diffs to be used conditionally
Closes #54670
See merge request gitlab-org/gitlab-ce!25432
|
|
Prepares suggestion implementation for multi-line support
See merge request gitlab-org/gitlab-ce!26057
|
|
Since external diffs are likely to be a bit slower than in-database
ones, add a mode that makes diffs external after they've been obsoleted
by events. This should strike a balance between performance and disk
space.
A background cron drives the majority of migrations, since diffs become
outdated through user actions.
|
|
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.
|
|
Error messages from custom pre-receive hooks now appear in the GitLab
UI.
This is re-enabling a feature that had been disabled in merge request
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18646
The feature had been disabled due to security concerns that information
which was not intended to be public (like stack traces) would leak into
public view.
PreReceiveErrors (from pre-receive, post-receive and update custom
hooks) are now filtered for messages that have been prefixed in a
particular way.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/48132
|
|
Fixes #56864
|
|
This reverts merge request !25708
|
|
Returns the source and target IDs used to create
the merge commit on Gitaly.
|
|
|
|
|
|
[master] Check issue milestone availability
See merge request gitlab/gitlabhq!2788
|
|
When a merge fails due to a locked file, no feedback was given to the
user as to why it failed if the user used the Merge button. However, if
the push attempt happened directly in the Web UI, the pre-receive
message would be displayed.
To be consistent and to make it clear why a merge failed, we now include
the pre-receive error message in the merge request widget.
Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/10165
|
|
Fix
ok
Add spec
Fix
ok
Fix
Add changelog
Fix
Add memoization
a
fix
|
|
|
|
|
|
Returns error in MergeToRefService when
merge_to_tmp_merge_ref_path ff is disabled.
|
|
Move authorization checks to merge services
instead relying solely on external checks.
|
|
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
|
|
Allow single tasks to be updated quickly
|
|
|
|
|
|
Sort out some logic
|
|
Bump Ruby on Rails to 5.0.7.1
See merge request gitlab-org/gitlab-ce!23396
|