Instead of sending varied data to Gitaly, and making Gitaly construct
various messages, build the messages first and have Gitaly print
either basic messages or alert messages, in the order they come.
Depends on https://gitlab.com/gitlab-org/gitaly/merge_requests/1410
`Gitlab::QueryLimiting.whitelist` has been moved from being inside the
feature flag conditional check to the `process_mr_push_options`
`Api::Internal` helper.
https://gitlab.com/gitlab-org/gitlab-ce/issues/60250
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.
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
This changes the repository type from a binary `wiki?` to a type. So
we can have more than 2 repository types.
Now everywhere we called `.wiki?` and expected a boolean, we check
that type.
This will enable us to track the human-readable project path with SSH
access in gitlab-shell. Currently the Gitaly logs will only show the
hashed storage and gl_repository path (e.g. project-1234).
GitLab Bot
Ash McKenzie
Michael Kozono
Mayra Cabrera
Luke Duncalfe
Bob Van Landuyt
Stan Hu
gfyoung
Zeger-Jan van de Weg
Jacob Vosmaer (GitLab)
Alejandro Rodríguez
Kim "BKC" Carlbäcker