Age | Commit message (Collapse) | Author |
|
Replaces the previous hardcoded timeouts for `git-upload-pack` and
`git-upload-archive` with values pulled from the TOML configuration. If
no values were provided by the user, default values are set in the `Cfg`
struct.
|
|
Adds a new `timeout` section to the TOML configuration file. This allows
users to customise the timeout values used for the negotiation phase of
the `git-upload-pack` and `git-upload-archive` operations, which may
time out for larger repositories.
The current default values of 10 minutes for git-upload-pack and 1
minute for git-upload-archive are preserved.
|
|
log: Strip down `Logger` interface and further encapsulate the `logrus.Entry`
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6399
Merged-by: Toon Claes <toon@gitlab.com>
Approved-by: James Liu <jliu@gitlab.com>
Approved-by: Toon Claes <toon@gitlab.com>
Co-authored-by: Patrick Steinhardt <psteinhardt@gitlab.com>
|
|
go: Update module github.com/getsentry/sentry-go to v0.24.1
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6394
Merged-by: Christian Couder <chriscool@tuxfamily.org>
Approved-by: Christian Couder <chriscool@tuxfamily.org>
Approved-by: Will Chandler <wchandler@gitlab.com>
Co-authored-by: GitLab Renovate Bot <gitlab-bot@gitlab.com>
|
|
The `log.LogrusLogger` type directly wraps the `logrus.Entry`, thus
exposing all of its functions. We don't want anybody to call them in the
ideal case so that we can ensure that we use our own logging interface
almost exclusively throughout the codebase.
Let's hide the `logrus.Entry` by making it a private member of the
`log.LogrusLogger`. While this requires us to explicitly implement some
of the expected interface-level functions, by now it's really only four
of them and thus manageable.
There are still some very limited callsites in our tests that require
access to the `logrus.Entry`, which will be addressed in another
iteration. Meanwhile, we expose an explicit `LogrusEntry()` getter that
makes the entry accessible to those usecases.
|
|
The functions `Debug()`, `Info()` and related accept multiple arguments.
The first hunch would be that the logger would format those arguments
via a call to `fmt.Sprintf()`, and that's seemingly also the assumption
that many of our callsites had. But in fact, the logrus logger will call
`fmt.Sprint()`, which joins the arguments by spaces when neither of the
arguments is a string.
While not being obvious, the current definition also conflicts with the
`slog` package. While the respective functions there also accept a
variable number of arguments, they will instead be interpreted as key
value pairs of structured data.
Let's simplify our calling conventions such that the functions only
accept a single message parameter and adjust callsites that misused
these functions accordingly. This fixes a source of misformatted log
messages and prepares us for the conversion to the `slog` package.
|
|
Drop `Debugln()` and related functions. The only difference to the
`Debug()` family of functions is that they use `fmt.Sprintln()` to
format the log message, which guarantees that the arguments will be
separated by a space. This difference is non-obvious and also not
supported by the `slog` package.
The only user of this function is the Yamux log wrapper, which we adapt
accordingly.
|
|
Remove `Panic` and related functions. The "panic" level is not known to
the `slog` package and thus cannot be emulated easily. We have no uses
of this function in our code base anyway.
|
|
Remove `Fatal` and related functions. The "fatal" level is not known to
the `slog` package and thus cannot be emulated easily. Replace all such
existing calls with a log message at "error" level followed by exiting
with an error code.
|
|
The `logrus.Logger` interface has both `Warn()` and `Warning()` and
related functions, and we have adopted these for our own `Logger`
interface. Let's remove the latter family of functions so that we only
keep the `Warn()` family of functions, which is also the interface
exposed by the `slog` package.
Note that the `badger` dependency requires the `Warning()`-style
functions. To address this, we again create a simple wrapper that
implements this specific interface.
|
|
The function family `Print{,f,ln}()` is merely a wrapper of the
respective functions that log a message at info level. Despite being
duplicate, it's also not obvious what they are doing and not supported
by the `slog` package.
Remove these functions from the `Logger` interface and replace all their
usages with the respective info-level functions. As the Yamux library
expects a logger implementing these functions this commit implements a
wrapper that forwards the respective functions.
|
|
Instrument start up time
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6393
Merged-by: Patrick Steinhardt <psteinhardt@gitlab.com>
Approved-by: Patrick Steinhardt <psteinhardt@gitlab.com>
Co-authored-by: Sami Hiltunen <shiltunen@gitlab.com>
|
|
[ci skip]
|
|
into 'master'
limiter: Add adaptive limit to the concurrency limiter (second attempt)
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6367
Merged-by: Patrick Steinhardt <psteinhardt@gitlab.com>
Approved-by: James Liu <jliu@gitlab.com>
Approved-by: Patrick Steinhardt <psteinhardt@gitlab.com>
Reviewed-by: Patrick Steinhardt <psteinhardt@gitlab.com>
Reviewed-by: Quang-Minh Nguyen <qmnguyen@gitlab.com>
Reviewed-by: James Liu <jliu@gitlab.com>
Co-authored-by: Quang-Minh Nguyen <qmnguyen@gitlab.com>
|
|
Do not assert repository path in UserUpdateBranch tests
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6390
Merged-by: Patrick Steinhardt <psteinhardt@gitlab.com>
Approved-by: Patrick Steinhardt <psteinhardt@gitlab.com>
Reviewed-by: Sami Hiltunen <shiltunen@gitlab.com>
Co-authored-by: Sami Hiltunen <shiltunen@gitlab.com>
|
|
go: Update module google.golang.org/grpc to v1.58.1
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6396
Merged-by: Will Chandler <wchandler@gitlab.com>
Approved-by: Quang-Minh Nguyen <qmnguyen@gitlab.com>
Approved-by: Will Chandler <wchandler@gitlab.com>
Co-authored-by: GitLab Renovate Bot <gitlab-bot@gitlab.com>
|
|
repository: Use sidechannel when creating fork
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6386
Merged-by: Quang-Minh Nguyen <qmnguyen@gitlab.com>
Approved-by: Quang-Minh Nguyen <qmnguyen@gitlab.com>
Approved-by: Patrick Steinhardt <psteinhardt@gitlab.com>
Approved-by: Justin Tobler <jtobler@gitlab.com>
Reviewed-by: Quang-Minh Nguyen <qmnguyen@gitlab.com>
Co-authored-by: Will Chandler <wchandler@gitlab.com>
|
|
This commit adds the adaptive limit to limiter.ConcurrencyLimiter. It
changes the signature of the initializer to receive an AdaptiveLimit
object and converts the queues in the limiter to dynamic pools. At this
point, as the calculator has not been integrated (yet), the input limit
never changes. It always returns a persistent limit, which is a perfect
replacement for the integer static limit.
In the future, when the calculator kicks in, the dynamic pools in the
concurrency limiter scale up and down accordingly when the current limit
is changed by the calculator.
|
|
|
|
Recently, when the context passed into resizableSemaphore.Acquire
exceeds the deadline, the resizable semaphore returns
context.DeadlineExceeded. This error is fine. However, the limiter
package has a custom error, ErrMaxQueueTime, for indicating the timeout
event. The counterpart returns this error instead. In addition,
resizableSemaphore.TryAcquire() also returns a custom error. Hence, it
makes sense to let the resizable semaphore returns ErrMaxQueueTime.
|
|
|
|
TestUserUpdateBranch_failingGitHooks is asserting the repository's
path as seen in the hooks. The paths may change so they should not be
asserted in the service tests. Its anyway an internal detail and not
something that service level tests should be testing for.
|
|
'master'
Treat reference conflicts as InvalidArgument errors
Closes #5482
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6380
Merged-by: karthik nayak <knayak@gitlab.com>
Approved-by: Justin Tobler <jtobler@gitlab.com>
Approved-by: Toon Claes <toon@gitlab.com>
|
|
|
|
Gitaly is starting exceedingly slow in some cases. We don't have
enough logs where the slow down happens to say which step in the
initialization process is the culprit. This commit outpus log
messages with the duration it took to execute a given initialization
step so we'll have a better idea what is taking so long.
|
|
conflict: Respect timezone info for new commits
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6371
Merged-by: Toon Claes <toon@gitlab.com>
Approved-by: Toon Claes <toon@gitlab.com>
Reviewed-by: Patrick Steinhardt <psteinhardt@gitlab.com>
Co-authored-by: Xing Xin <xingxin.xx@bytedance.com>
|
|
into 'master'
go: Update google.golang.org/genproto/googleapis/rpc digest to 007df8e
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6358
Merged-by: Quang-Minh Nguyen <qmnguyen@gitlab.com>
Approved-by: Quang-Minh Nguyen <qmnguyen@gitlab.com>
Co-authored-by: GitLab Renovate Bot <gitlab-bot@gitlab.com>
|
|
Flaky tests: Fix TestAdaptiveCalculator flaky tests (second take)
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6381
Merged-by: Quang-Minh Nguyen <qmnguyen@gitlab.com>
Approved-by: Justin Tobler <jtobler@gitlab.com>
|
|
go: Update module github.com/miekg/dns to v1.1.56
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6384
Merged-by: Justin Tobler <jtobler@gitlab.com>
Approved-by: Quang-Minh Nguyen <qmnguyen@gitlab.com>
Approved-by: Justin Tobler <jtobler@gitlab.com>
Co-authored-by: GitLab Renovate Bot <gitlab-bot@gitlab.com>
|
|
limithandler: Quarantine `TestUnaryLimitHandler_queueing`
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6389
Merged-by: Will Chandler <wchandler@gitlab.com>
Approved-by: Will Chandler <wchandler@gitlab.com>
Co-authored-by: Justin Tobler <jtobler@gitlab.com>
|
|
The `TestUnaryLimitHandler_queueing` test is flaky resulting in pipeline
failures. Quarantine the test to skip execution.
|
|
`CreateFork()` uses the old `SSHUploadPack` method when fetching the
original repository, rather than the more efficient
`SSHUploadPackWithSidechannel`. Update it to use the latter.
|
|
featureflag: Remove the `GitV242` flag
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6378
Merged-by: Christian Couder <chriscool@tuxfamily.org>
Approved-by: Christian Couder <chriscool@tuxfamily.org>
Co-authored-by: Karthik Nayak <knayak@gitlab.com>
|
|
This commit serves as an addition to the fix for commit signatures
mentioned in [1]. Although we have fixed commit signatures for RPCs in
operations service, we unintentionally neglected the fact that
ResolveConflicts in conflicts service also generates new commits.
1. https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6323
Signed-off-by: Xing Xin <xingxin.xx@bytedance.com>
|
|
|
|
|
|
service: Simplify injection of dependencies for servers
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6377
Merged-by: Patrick Steinhardt <psteinhardt@gitlab.com>
Approved-by: karthik nayak <knayak@gitlab.com>
Reviewed-by: James Liu <jliu@gitlab.com>
Reviewed-by: karthik nayak <knayak@gitlab.com>
|
|
The featureflag `GitV242` was introduced to rollout git v2.42. Since the
rollout was completed in the previous release (16.4), we can safely
remove the flag.
|
|
While we already have a `service.Dependencies` type around for quite a
long time, we still pass in dependencies explicitly when constructing
the actual server. This makes it harder than necessary to make a server
require more dependencies as you will have to adjust all callsites where
the server is currently getting constructed.
Simplify the code to instead inject the `service.Dependencies` type into
the server directly. This will allow us to propagate dependencies more
readily in the future.
|
|
ssh: Unify logic to handle git-upload-pack(1) and git-upload-archive(1)
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6379
Merged-by: James Liu <jliu@gitlab.com>
Approved-by: Quang-Minh Nguyen <qmnguyen@gitlab.com>
Approved-by: James Liu <jliu@gitlab.com>
Reviewed-by: Patrick Steinhardt <psteinhardt@gitlab.com>
Reviewed-by: Quang-Minh Nguyen <qmnguyen@gitlab.com>
Reviewed-by: James Liu <jliu@gitlab.com>
Co-authored-by: Patrick Steinhardt <psteinhardt@gitlab.com>
|
|
While we already have a `service.Dependencies` type around for quite a
long time, we still pass in dependencies explicitly when constructing
the actual server. This makes it harder than necessary to make a server
require more dependencies as you will have to adjust all callsites where
the server is currently getting constructed.
Simplify the code to instead inject the `service.Dependencies` type into
the server directly. This will allow us to propagate dependencies more
readily in the future.
|
|
While we already have a `service.Dependencies` type around for quite a
long time, we still pass in dependencies explicitly when constructing
the actual server. This makes it harder than necessary to make a server
require more dependencies as you will have to adjust all callsites where
the server is currently getting constructed.
Simplify the code to instead inject the `service.Dependencies` type into
the server directly. This will allow us to propagate dependencies more
readily in the future.
|
|
While we already have a `service.Dependencies` type around for quite a
long time, we still pass in dependencies explicitly when constructing
the actual server. This makes it harder than necessary to make a server
require more dependencies as you will have to adjust all callsites where
the server is currently getting constructed.
Simplify the code to instead inject the `service.Dependencies` type into
the server directly. This will allow us to propagate dependencies more
readily in the future.
|
|
While we already have a `service.Dependencies` type around for quite a
long time, we still pass in dependencies explicitly when constructing
the actual server. This makes it harder than necessary to make a server
require more dependencies as you will have to adjust all callsites where
the server is currently getting constructed.
Simplify the code to instead inject the `service.Dependencies` type into
the server directly. This will allow us to propagate dependencies more
readily in the future.
|
|
While we already have a `service.Dependencies` type around for quite a
long time, we still pass in dependencies explicitly when constructing
the actual server. This makes it harder than necessary to make a server
require more dependencies as you will have to adjust all callsites where
the server is currently getting constructed.
Simplify the code to instead inject the `service.Dependencies` type into
the server directly. This will allow us to propagate dependencies more
readily in the future.
|
|
While we already have a `service.Dependencies` type around for quite a
long time, we still pass in dependencies explicitly when constructing
the actual server. This makes it harder than necessary to make a server
require more dependencies as you will have to adjust all callsites where
the server is currently getting constructed.
Simplify the code to instead inject the `service.Dependencies` type into
the server directly. This will allow us to propagate dependencies more
readily in the future.
|
|
While we already have a `service.Dependencies` type around for quite a
long time, we still pass in dependencies explicitly when constructing
the actual server. This makes it harder than necessary to make a server
require more dependencies as you will have to adjust all callsites where
the server is currently getting constructed.
Simplify the code to instead inject the `service.Dependencies` type into
the server directly. This will allow us to propagate dependencies more
readily in the future.
|
|
While we already have a `service.Dependencies` type around for quite a
long time, we still pass in dependencies explicitly when constructing
the actual server. This makes it harder than necessary to make a server
require more dependencies as you will have to adjust all callsites where
the server is currently getting constructed.
Simplify the code to instead inject the `service.Dependencies` type into
the server directly. This will allow us to propagate dependencies more
readily in the future.
|
|
While we already have a `service.Dependencies` type around for quite a
long time, we still pass in dependencies explicitly when constructing
the actual server. This makes it harder than necessary to make a server
require more dependencies as you will have to adjust all callsites where
the server is currently getting constructed.
Simplify the code to instead inject the `service.Dependencies` type into
the server directly. This will allow us to propagate dependencies more
readily in the future.
|
|
While we already have a `service.Dependencies` type around for quite a
long time, we still pass in dependencies explicitly when constructing
the actual server. This makes it harder than necessary to make a server
require more dependencies as you will have to adjust all callsites where
the server is currently getting constructed.
Simplify the code to instead inject the `service.Dependencies` type into
the server directly. This will allow us to propagate dependencies more
readily in the future.
|