An error occurred fetching the project authors.
- 06 Mar, 2019 1 commit
-
-
Andrew Newdigate authored
This style change enforces `return if ...` instead of `return nil if ...` to save maintainers a few minor review points
-
- 28 Feb, 2019 1 commit
-
-
Nick Thomas authored
This reverts commit 00675311.
-
- 22 Feb, 2019 1 commit
-
-
Zeger-Jan van de Weg authored
Prior to this change, 35 Gitaly RPCs were allowed. But recently there's been a renewed interest in performance. By lowering the number of calls new N + 1's will pop up. Later commits will add blocks to ignore the raised errors, followed by an issue for each to be fixed.
-
- 25 Jan, 2019 1 commit
-
-
Valery Sizov authored
Backport of https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/7434
-
- 22 Jan, 2019 1 commit
-
-
Andrew Newdigate authored
This change allows the GitLab rails and sidekiq components to receive tracing spans from upstream services such as Workhorse and pass these spans on to downstream services including Gitaly and Sidekiq. This change will also emit traces for incoming and outgoing requests using the propagated trace information. This will allow operators and engineers to view traces across the Workhorse, GitLab Rails, Sidekiq and Gitaly components. Additional intra-service instrumentation will be added in future changes.
-
- 20 Dec, 2018 1 commit
-
-
Ahmad Hassan authored
-
- 19 Dec, 2018 1 commit
-
-
Ahmad Hassan authored
-
- 17 Dec, 2018 1 commit
-
-
Ahmad Hassan authored
-
- 11 Dec, 2018 1 commit
-
-
Ahmad Hassan authored
-
- 07 Dec, 2018 1 commit
-
-
Andrew Newdigate authored
-
- 06 Dec, 2018 3 commits
-
-
Kamil Trzciński authored
This reverts commit 3560b119.
-
Kamil Trzciński authored
This changes `correlation_id` to be `correlation-id` when passed via jobs
-
Kamil Trzciński authored
The Correlation ID is taken or generated from received X-Request-ID. Then it is being passed to all executed services (sidekiq workers or gitaly calls). The Correlation ID is logged in all structured logs as `correlation_id`.
-
- 27 Nov, 2018 1 commit
-
-
Ahmad Hassan authored
-
- 20 Nov, 2018 3 commits
-
-
Zeger-Jan van de Weg authored
On HEAD~ we remove the ID from the class, which created a bug. Given we don't need the ID anymore, it has been removed and simplified.
-
Zeger-Jan van de Weg authored
This reverts merge request !23229
-
Sean McGivern authored
This reverts merge request !23140
-
- 16 Nov, 2018 1 commit
-
-
Zeger-Jan van de Weg authored
Now only the data was shown of the service, which is not valueable at times given some of those expose a lot of RPCs.
-
- 15 Nov, 2018 1 commit
-
-
George Tsiolis authored
-
- 31 Oct, 2018 1 commit
-
-
Ahmad Hassan authored
-
- 30 Oct, 2018 1 commit
-
-
Ahmad Hassan authored
-
- 22 Oct, 2018 1 commit
-
-
gfyoung authored
-
- 05 Oct, 2018 1 commit
-
-
James Lopez authored
This reverts merge request !21520
-
- 24 Sep, 2018 1 commit
-
-
Michael Kozono authored
Even if it doesn’t save lines of code, since people will tend to use code they’ve seen. And `SafeRequestStore` is safer since you don’t have to remember to check `RequestStore.active?`.
-
- 20 Sep, 2018 1 commit
-
-
Alejandro Rodríguez authored
-
- 06 Sep, 2018 1 commit
-
-
James Lopez authored
-
- 24 Jul, 2018 1 commit
-
-
Zeger-Jan van de Weg authored
-
- 09 Jul, 2018 1 commit
-
-
Lin Jen-Shin authored
-
- 04 Jul, 2018 1 commit
-
-
Sean McGivern authored
We don't need to know the details of every library involved in these calls; they will always originate in the GitLab app itself.
-
- 14 Jun, 2018 1 commit
-
-
Jacob Vosmaer (GitLab) authored
-
- 06 Jun, 2018 3 commits
-
-
Jacob Vosmaer authored
-
Jacob Vosmaer authored
-
Zeger-Jan van de Weg authored
Gitaly itself hold very little state, other than the data on disk. This limits the interfaces to set feature flags. Gitaly now has the ability to interpret the request metadata to check for feature flags. https://gitlab.com/gitlab-org/gitaly/merge_requests/704 This allows clients control on the Gitaly server, and given that Rails has an internal chatops interface to set these values this was chosen as solution. Known limitation right now, is that this package doesn't support the opt out that other Gitaly features do.
-
- 01 Jun, 2018 1 commit
-
-
Jacob Vosmaer (GitLab) authored
-
- 27 Mar, 2018 1 commit
-
-
Zeger-Jan van de Weg authored
When a repository does not exist on a remote, Gitaly won't be able to clone it. This is correct behaviour, but from the clients perspective a change in behaviour. This change implements the client side changes that allows Gitaly to execute a `git ls-remote <remote-url> HEAD`. This way the client has no need to shell out to Git. In the situation where multiple Gitalies are available, one is chosen at random. This commit closes https://gitlab.com/gitlab-org/gitlab-ce/issues/43929, while its also a part of https://gitlab.com/gitlab-org/gitaly/issues/1084
-
- 13 Mar, 2018 2 commits
-
-
Sean McGivern authored
-
Sean McGivern authored
The same as the SQL queries, show the details of Gitaly calls in the performance bar, as a modal that can be opened in the same way.
-
- 26 Feb, 2018 1 commit
-
-
Jacob Vosmaer (GitLab) authored
-
- 29 Jan, 2018 2 commits
-
-
Pawel Chojnacki authored
-
Pawel Chojnacki authored
/cc @bjk-gitlab /cc @zj
-