An error occurred fetching the project authors.
- 03 Jan, 2020 1 commit
-
-
Bob Van Landuyt authored
This provides context to all requests made to Rails controllers or grape endpoints. Doing this starts a new `Labkit::Context`, to which we can provide a namespace, project and user. We're currently setting the following values: - Web requests: In the ApplicationController we wrap the entire request in a `with_context`. - user: based on the `auth_user` if there is one - project: We try to read the @project instance variable of the controller. - namespace: We try to read the @group instance variable of the controller. If there was none, but the project was set, we'll use that path to set the namespace - API requests: The application context is pushed in a before block setting the following values: - user: to `current_user` if there is one - project: to `@project` - namespace: to `@group` - Internal API requests: the application context is pushed in a before block: - user: When to the user set in `Api::Support::GitAccessActor` - project: to @project if it was available The 3 supported attributes for a context are read lazily when required. This also replaces the existing correlation middlewares with the new Labkit::Context middlewares. The rack middleware wraps each rack request in an overarching context that adds the correlation id. The context is cleaned up after the request, so we're sure all child contexts are cleaned up as well. The sidekiq client middleware will write the context into the job that goes into redis when a job is scheduled. The sidekiq server middleware will then re-instantiate this context so the job gets executed with the same context that was alive when it was scheduled. This means that any new job scheduled from sidekiq would also have this context.
-
- 27 Dec, 2019 1 commit
-
-
Francisco Javier López authored
Refactor some methods, classes and specs in preparation for versioned snippets.
-
- 24 Dec, 2019 1 commit
-
-
Paul Okstad authored
Part of https://gitlab.com/gitlab-org/gitaly/issues/2292 Related to https://gitlab.com/gitlab-org/gitaly/issues/2288 This change is essentially a revert of https://gitlab.com/gitlab-org/gitlab/merge_requests/18766. Due to an issue found in production (see https://gitlab.com/gitlab-com/gl-infra/production/issues/1501#note_262058610), the cache invalidator needs to be disabled until the cache walker is able to remove empty directories. This feature flag will allow us to reenable the cache invalidator when we are ready to test the updated cache walker.
-
- 18 Dec, 2019 1 commit
-
-
Alessio Caiazza authored
This reverts commit 1578bae2, reversing changes made to 849b2c77.
-
- 12 Dec, 2019 2 commits
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
Heinrich Lee Yu authored
The feature flag was removed but the spec was not updated causing a failure in master
-
- 05 Dec, 2019 1 commit
-
-
Pavlo Strokov authored
Feature flag to change between old ruby and new go implementations of Gitaly gRPC call to FilterShasWithSignatures. Part of https://gitlab.com/gitlab-org/gitaly/issues/2157
-
- 03 Dec, 2019 1 commit
-
-
Bob Van Landuyt authored
Reuse the `Support::GitAccessActor` to find an actor for the internal API. That way we're a bit closer to having a single way of accessing the user.
-
- 19 Nov, 2019 1 commit
-
-
Pavlo Strokov authored
- fix tests after new feature flag added Related to https://gitlab.com/gitlab-org/gitaly/issues/2123
-
- 28 Oct, 2019 1 commit
-
-
gfyoung authored
Partially addresses: https://gitlab.com/gitlab-org/gitlab/issues/27703
-
- 24 Oct, 2019 1 commit
-
-
Ash McKenzie authored
-
- 21 Oct, 2019 1 commit
-
-
Ash McKenzie authored
-
- 10 Oct, 2019 1 commit
-
-
Bob Van Landuyt authored
The broadcast messages have been added to the `post_receive` endpoint in https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/13916. So these endpoints are no longer used
-
- 09 Oct, 2019 2 commits
-
-
Bob Van Landuyt authored
This removes the ability to call `/internal/discover` with a user id. As this was not used anymore.
-
Bob Van Landuyt authored
This was added in https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/5542 but has been replaced by the post receive call in https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/13916
-
- 24 Sep, 2019 1 commit
-
-
John Cai authored
-
- 04 Sep, 2019 1 commit
-
-
Krasimir Angelov authored
Squashed commits: c4b804c6
-
- 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
-
- 10 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.
-
- 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
- 05 Apr, 2019 1 commit
-
-
Bob Van Landuyt authored
This makes sure that we always have a repository type when trying to parse a repository from a path. This is needed because sometimes we want to perform access checks as if the project already existed, for example when creating a project on push. Before this we were only doing that when accessing git over http, this makes sure it also works correctly when accessing git over SSH
-
- 04 Apr, 2019 2 commits
-
-
Ash McKenzie authored
Currently a no-op for CE
-
Ash McKenzie authored
gl_console_messages is now returned in the payload that is processed by gitlab-shell and will be printed to $stderr if present.
-
- 26 Mar, 2019 2 commits
-
-
Bob Van Landuyt authored
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.
-
Bob Van Landuyt authored
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.
-
- 12 Mar, 2019 1 commit
-
-
Fabio Papa authored
The repository_path is no longer needed since https://gitlab.com/gitlab-org/gitlab-shell/merge_requests/231, which closes https://gitlab.com/gitlab-org/gitlab-shell/issues/135.
-
- 11 Mar, 2019 2 commits
-
-
Bob Van Landuyt authored
Instead of mixing in the shared secret into the querystring or body, we could also specify it in a header.
-
Bob Van Landuyt authored
The behavior for GitLab shell calling `/discover` when a user is not found is currently untested. We are relying on this behaviour to make GitLab reply "Welcome to GitLab, Anonymous!".
-
- 16 Feb, 2019 1 commit
-
-
Stan Hu authored
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).
-
- 15 Feb, 2019 1 commit
-
-
Ash McKenzie authored
When using git-lfs with SSH we weren't passing in the expires_header header which is allows large transfers to succeed in the event the current default of 30 mins expires. https://github.com/git-lfs/git-lfs/blob/master/docs/api/server-discovery.md#ssh
-
- 14 Feb, 2019 1 commit
-
-
Ash McKenzie authored
When using git-lfs with SSH we weren't passing in the expires_header header which is allows large transfers to succeed in the event the current default of 30 mins expires. https://github.com/git-lfs/git-lfs/blob/master/docs/api/server-discovery.md#ssh
-