An error occurred fetching the project authors.
- 27 Feb, 2020 1 commit
-
-
GitLab Bot authored
-
- 26 Feb, 2020 1 commit
-
-
GitLab Bot authored
-
- 18 Feb, 2020 1 commit
-
-
GitLab Bot authored
-
- 17 Feb, 2020 1 commit
-
-
GitLab Bot authored
-
- 12 Feb, 2020 1 commit
-
-
GitLab Bot authored
-
- 10 Feb, 2020 1 commit
-
-
GitLab Bot authored
-
- 29 Jan, 2020 1 commit
-
-
GitLab Bot authored
-
- 28 Jan, 2020 1 commit
-
-
GitLab Bot authored
-
- 27 Jan, 2020 1 commit
-
-
GitLab Bot authored
-
- 24 Jan, 2020 1 commit
-
-
GitLab Bot authored
-
- 23 Jan, 2020 1 commit
-
-
GitLab Bot authored
-
- 21 Jan, 2020 1 commit
-
-
GitLab Bot authored
-
- 20 Jan, 2020 1 commit
-
-
GitLab Bot authored
-
- 03 Jan, 2020 1 commit
-
-
GitLab Bot authored
-
- 27 Dec, 2019 1 commit
-
-
GitLab Bot authored
-
- 24 Dec, 2019 1 commit
-
-
GitLab Bot authored
-
- 18 Dec, 2019 1 commit
-
-
GitLab Bot authored
-
- 16 Dec, 2019 1 commit
-
-
GitLab Bot authored
-
- 12 Dec, 2019 1 commit
-
-
GitLab Bot authored
-
- 09 Dec, 2019 1 commit
-
-
GitLab Bot authored
-
- 04 Dec, 2019 1 commit
-
-
GitLab Bot authored
-
- 20 Nov, 2019 1 commit
-
-
GitLab Bot authored
-
- 29 Oct, 2019 1 commit
-
-
GitLab Bot authored
-
- 24 Oct, 2019 1 commit
-
-
GitLab Bot authored
-
- 23 Oct, 2019 1 commit
-
-
GitLab Bot authored
-
- 10 Oct, 2019 2 commits
-
-
GitLab Bot authored
-
GitLab Bot authored
-
- 09 Oct, 2019 1 commit
-
-
GitLab Bot authored
-
- 24 Sep, 2019 1 commit
-
-
GitLab Bot authored
-
- 03 Sep, 2019 1 commit
-
-
Krasimir Angelov authored
so that we can use API::Internal namespace. Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/61927.
-
- 28 Aug, 2019 1 commit
-
-
Michael Kozono authored
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
-
- 09 Jul, 2019 1 commit
-
-
Bob Van Landuyt authored
Some of the specs were using namespace names instead of paths for building URLS. This would fail since we now build a namespace with a user's name instead of a user's username.
-
- 17 May, 2019 1 commit
-
-
Luke Duncalfe authored
`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
-
- 03 May, 2019 1 commit
-
-
Stan Hu authored
When creating a merge request for push options, there may be over 100 queries that are run to create a merge request. Even after we reduce the number of queries by disabling the Sidekiq jobs, it appears we still hover near this limit. Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/11450
-
- 16 Apr, 2019 1 commit
-
-
Luke Duncalfe authored
The intention of this test is to ensure that the service class MergeRequests::PushOptionsHandlerService does not run when the :mr_push_options feature flag is disabled. This test was passing, however was not testing what it was supposed to be! For one, setting Feature.disable(:feature) in the test does not disable the feature, as rspec config in spec_helper stubs Feature to make all features enabled: https://gitlab.com/gitlab-org/gitlab-ce/commit/3ee48e422defaedd69946c607bd8d3672e510375 So the feature was still enabled in the test. But this test wasn't failing because unfortunately I had put: ``` expect(MergeRequests::PushOptionsHandlerService).to receive(:new) ``` instead of not_to! This meant that the `.new` method was being stubbed, so the service class did not create a MergeRequest, which satisfied the second expectation. ``` expect(MergeRequests::PushOptionsHandlerService).to receive(:new) ```
-
- 08 Apr, 2019 5 commits
-
-
Luke Duncalfe authored
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.
-
Luke Duncalfe authored
Previously the raw push option Array was sent to Pipeline::Chain::Skip. This commit updates this class (and the chain of classes that pass the push option parameters from the API internal `post_receive` endpoint to that class) to treat push options as a Hash of options parsed by GitLab::PushOptions. The GitLab::PushOptions class takes options like this: -o ci.skip -o merge_request.create -o merge_request.target=branch and turns them into a Hash like this: { ci: { skip: true }, merge_request: { create: true, target: 'branch' } } This now how Pipeline::Chain::Skip is determining if the `ci.skip` push option was used.
-
Luke Duncalfe authored
-
Luke Duncalfe authored
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