| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Since the introduction of Praefect, our code layout started to become
confusing: while Praefect code lives in `internal/praefect`,
Gitaly-specific code is all over the place and not neatly singled out.
This makes it hard at times to tell apart Praefect- and Gitaly-specific
from generic code.
To improve the situation, this commit thus moves most of the server
specific code into a new `internal/gitaly` package. Currently, this is
the `internal/config`, `internal/server`, `internal/service` and
`internal/rubyserver` packages, which are all main components of Gitaly.
The move was realized with the following script:
#!/bin/sh
mkdir -p internal/gitaly
git mv internal/{config,server,service,rubyserver} internal/gitaly/
find . -name '*.go' -exec sed -i \
-e 's|gitlab-org/gitaly/internal/rubyserver|gitlab-org/gitaly/internal/gitaly/rubyserver|' \
-e 's|gitlab-org/gitaly/internal/server|gitlab-org/gitaly/internal/gitaly/server|' \
-e 's|gitlab-org/gitaly/internal/service|gitlab-org/gitaly/internal/gitaly/service|' \
-e 's|gitlab-org/gitaly/internal/config|gitlab-org/gitaly/internal/gitaly/config|' {} \;
In addition to that, some minor adjustments were needed for tests which
used relative paths.
|
|
Since 489e4eac (linguist: Use configured Git executable, 2020-08-19), we
modify git-linguist's PATH environment variable in order to have it use
the correct Git executable. This is mostly done as git-linguist doesn't
allow us to pick a Git executable, so we need prepend the real Git
executable's directory to PATH.
This hack has caused a regression, though: in case the Git directory
also contains bundle(1), then we now potentially use the wrong bundle
version and thus also the wrong version of Ruby. As a result, execution
will fail.
Fix the issue by resolving bundle to an absolute path and using that one
instead.
|
|
When executing git-linguist, one of the first things it'll do is verify
whether it's running in a Git directory by executing `git rev-parse
--git-dir`. git-linguist doesn't allow specifying which Git executable
is executed here, so it'll always use the first one it finds in PATH,
which isn't necessarily the one configured in Gitaly's configuration.
Fix the issue by always prepending the configured Git executable's
directory to PATH previous to executing git-linguist. As our own command
interface will overwrite and PATH environment variables passed to it, we
need to use a hack here and specify the PATH variable by executing
git-linguist with `env PATH=$GITDIR:$PATH`.
|
|
Introduced in: be6d4c122dd158a72291b043623b41a60bf28964, this feature
was never turned on. As such it will be removed by this commit.
The proto changes remain, and will be removed next release.
Part of: https://gitlab.com/gitlab-org/gitaly/-/issues/2875
|
|
When running Git linguist on a repository, Gitaly tries to parse output
which is not intended to be parsed as the exit code might be
non-zero. Gitaly expect success on the command, and JSON output. On an
error, the output is an error message string, not in JSON.
This creates parsing errors, and issues like:
https://gitlab.com/gitlab-org/gitaly/-/issues/2294. The current change
checks the exit status of the command, where the expectation is that
linguist will never output invalid JSON if the exit code is zero.
Other cases will bubble up the error string in the error itself.
|
|
This change extends the CommitLanguage response to include FileCount and
Bytes. Getting the FileCount per language requires an additional
git-linguist call which might increase the GRPC call execution time.
To have control over the FileCount call, a new feature flag
('linguist_file_count_stats') has been introduced that can be turned off
when performance issues occur.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
