| Age | Commit message (Collapse) | Author |
|---|
|
Gitaly supports different execution environments with bundled Git and
distributed Git. If no such execution environment was properly set up
though we will fall back to try and resolve Git via PATH as a last
resort. Due to the way our environment constructors are arranged right
now though the fallback will always be constructed, which ultimately
leads to a warning that Git wasn't properly configured even though it in
fact was.
Fix this issue by removing the fallback Git environment from our default
constructors. Instead, we explicitly construct it only in the case where
we didn't find any other available execution environment. Like this, we
can now only print the warning when it actually applies.
Changelog: fixed
|
|
server: Introduce drift_threshold with proper type to replace drift_threshold_millis
Closes #4412
See merge request gitlab-org/gitaly!4788
|
|
As drift_threshold_millis field is deprecated we use a newly
added drift_threshold field instead. To support backwards compatibility
the old drift_threshold_millis is taken into account if there
is no value provided for the drift_threshold field.
Closes: https://gitlab.com/gitlab-org/gitaly/-/issues/4412
|
|
The existing drift_threshold_millis field uses int64 type, but
instead it should be of type google.protobuf.Duration.
The new field drift_threshold of the proper type added to be
used instead.
Part of: https://gitlab.com/gitlab-org/gitaly/-/issues/4412
|
|
linguist: Ensure empty files are omitted in totals
Closes #4416
See merge request gitlab-org/gitaly!4791
|
|
In the previous commit we've created a fix in the language stats, but
there still might be faulty values cached. To invalidate those, update
the version so we'll always recalculate stats from scratch unless it was
calculated with the fix in place.
|
|
Empty files should not be taken into account when calculation totals,
because the totals should have no languages that have a count of zero.
The linguist gem did this correctly already, but the newer Go
implementation didn't.
Issue: https://gitlab.com/gitlab-org/gitaly/-/issues/4416
Changelog: fixed
|
|
The ByteCountPerLanguage type is equal to map[string]uint64, so use the
type definition instead.
|
|
To make sure test cases are independent from eachother, convert the
existing test cases to table-based tests that set up a repository from
scratch each run.
|
|
[ci skip]
|
|
praefect: Check of the service readiness with RPC call
See merge request gitlab-org/gitaly!4674
|
|
Don't start of with a pre-existing repo, but instead build the commits
dynamically on demand. This prepares for testing with the SHA256 object
hashes.
|
|
The test coverage of TestInstance_Stats_incremental and
TestInstance_Stats/old_cache is nearly identical, so remove the
duplicate test.
|
|
I noticed when none of both fields is set, the user is presented with
the error saving "entry cannot have both OID and content". And when both
fields are set, no error is given.
Fix this by correctly error out when length of both is greater than
zero.
|
|
For the praefect binary we have a sub-command to verify
if praefect service can operate without issues. The
verification process checks if migrations were applied,
if gitaly nodes are reachable, if the clock synced, etc.
This check can be done only when you have direct access
to the binary. With introducing of ReadinessCheck RPC
we now can run the same verification process mentioned
above by issuing an RPC call.
The new RPC will be part of the gitlab:gitaly:check task.
It is noop for the gitaly service as of now.
Part of: https://gitlab.com/gitlab-org/gitlab/-/issues/348174
|
|
It is hard to test ReadinessCheck RPC because the set of the
checks that is executed is hard or not possible to mock or
substitute. Those we made check an injectable to provide from
outside. It will help us to write better tests for the RPC.
|
|
To test ReadinessCheck RPC we need to run praefect service.
The runPraefectServer function does what we need, but it is
not exportable. This change moves and renames runPraefectServer
and related code, so it can be re-used in other packages for
testing.
|
|
The set of the checks that is used to make sure praefect is ready
to serve the requests is moved to another location. That is done
because we should be able to call them from the RPC handler as
they will be used by the ReadinessCheck RPC.
Part of: https://gitlab.com/gitlab-org/gitlab/-/issues/348174
|
|
The new ReadinessCheck RPC added. It will allow to check the
service readiness and should be triggered before putting traffic
on to the service. In case of the failure the details about an
error and the check name would be returned to the caller.
Part of: https://gitlab.com/gitlab-org/gitlab/-/issues/348174
|
|
lstree: Support SHA256 object hash
See merge request gitlab-org/gitaly!4789
|
|
repository: Fix passing zero OID to WriteRef
See merge request gitlab-org/gitaly!4794
|
|
In ceb9161b1 (repository: Resolve revisions passed to the WriteRef RPC,
2022-07-29) we have refactored the `WriteRef()` RPC to resolve both old
and new revision before executing git-update-ref(1) in order to ensure
that the objects we want to update to actually exist. This refactoring
broke the case though where the client passes the all-zeroes object ID
either as old or new reference, which both have a well-defined meaning
in this context.
Fix this bug by special-casing the all-zeroes object ID.
Changelog: fixed
|
|
hook: Remove PackObjectsMetric feature flag
See merge request gitlab-org/gitaly!4786
|
|
'master'
go: Update module gitlab.com/gitlab-org/gitlab-shell/v14 to v14.10.0
See merge request gitlab-org/gitaly!4764
|
|
updateref: Support repositories with SHA256 object hashes
See merge request gitlab-org/gitaly!4778
|
|
go: Update module github.com/hashicorp/yamux to v0.1.1
See merge request gitlab-org/gitaly!4749
|
|
git: Speed up fetches by disabling the logic to show forced updates
Closes #4377
See merge request gitlab-org/gitaly!4783
|
|
Capture stderr on CreateFork
See merge request gitlab-org/gitaly!4785
|
|
git: Upgrade default Git distribution to v2.37.1.gl1
Closes #4193
See merge request gitlab-org/gitaly!4787
|
|
Exclude github.com/gin-gonic/gin vulnerable to CVE-2020-28483
Closes #3629
See merge request gitlab-org/gitaly!4784
|
|
git: Default-enable use of Git v2.37.1.gl1
See merge request gitlab-org/gitaly!4782
|
|
The lstree package supports both SHA1 and SHA256-based repositories.
Enable testing of the SHA256 object hash.
|
|
Detect the object hash used by the repository for which we should list
tree entries to support SHA256-based repositories.
|
|
Inject the object hash used to parse tree entries so that the tree entry
parser can easily support parsing both SHA1 and SHA256 tree entries. For
the time being all callers just inject SHA1. They will be converted over
time to inject the correct value.
|
|
We're using a seeded repository to test `ListEntries()` even though we
generate all test data at runtime anyway. Convert the tests to use
`gittest.InitRepo()` instead.
|
|
The lstree's parser tests use static data of git-ls-tree(1) that has
been written into a set of files. This makes it hard to test this
package with SHA256 given that the output of course contains SHA1 object
hashes.
Refactor the tests to instead generate data at runtime. Note that we're
removing one of the two testcases in this process: both testcases do in
fact exercise the exact same logic, only that one of both has a space in
one of its tree entries. So we just retain the test for the tree entry
with the space and discard the other one given that they don't really
test different things anyway.
|
|
The `WriteTree()` helper function doesn't allow writing tree entries
referring to a submodule right now. Add this functionality.
|
|
Now that we have default-enabled bundled Git v2.37.1.gl1 we can also
switch our default Git distribution to that newer Git version. Do so.
Changelog: changed
|
|
The updateref package needs to be able to verify object hashes, which
mandates that it must be able to tell which object hash format a repo is
using and to provide the correct zero object ID.
Add object hash detection logic and enable testing the package with
SHA256.
|
|
Change the updateref package to accept object IDs as old and new
target of the reference that is to be updated. This increases type
safety and better documents the intent of provided functions.
|
|
One of our tests for the `UpdaterWithHooks` structure is hardcoding the
use of the SHA1 object hash. Refactor it to instead use the current
default object hash as dictated by the `gittest` package. While at it,
set up the Git command factory that the test will start to require when
we auto-detect the object hash used by a repository.
|
|
Convert the tests of the updateref package to not use a seeded
repository so that we can test the package with both SHA1 and SHA256
object hashes.
|
|
Adjust test names of the updateref package to match modern best
practices and parallelize the tests.
|
|
When we rescue dangling objects in an object pool we execute git-fsck(1)
to find out about any objects which are not currently referenced. We
don't perform any sanity checks though on the output of git-fsck(1): the
only thing we do is to split the string, and then pass whatever data we
have obtained to git-update-ref(1).
Verify that the obtained data is actually a conforming object hash by
parsing the object ID. This also prepares for an upcoming change where
the updateref package will start to accept `git.ObjectID`s instead of
bare strings.
|
|
The WriteRef RPC gets as input a reference name that is to be updated as
well as the old and new revisions that the reference should be updated
from respectively to. It's not entirely clear what these revisions
contain: while one would typically expect it to only ever contain object
IDs, that may or may not be the case.
Resolve the revision to an object ID before invoking git-update-ref(1)
with them. This will ease the transition when we migrate the updateref
package to only ever accept object IDs as input, but it will also give
us better indicators when the revision does not exist in the repository.
|
|
This feature flag has been running in production without any issues. We
can now remove it now.
|
|
catfile: Support repositories with SHA256 object hashes
See merge request gitlab-org/gitaly!4779
|
|
CreateFork had been returning unhelpful exit status errors that are too
ambiguous to allow for debugging.
|
|
The affected versions are transitive dependencies of gocloud.dev which
is used by gitaly-backup to upload backups to object storage. This
feature has not been hooked up to backup.rake. There is no risk of
exploitation.
Changelog: security
|
|
server: Give clients grace-period for keepalives
Closes #4397
See merge request gitlab-org/gitaly!4772
|
