Age | Commit message (Collapse) | Author |
|
The `make git` target is kind of misnamed as it doesn't indicate that it
is about installing the Git distribution, but rather sounds like it
would only build it. Let's introduce a new `install-git` target that
clearly indicates that we're about to install it. This deprecates the
old `make git` rule, which is now simply an alias.
|
|
Now that our tests don't depend on the `git` target anymore it should
really only ever be used to actually install a Git distribution. It's
thus not all that sensible anymore to have it depend on the target
location: Git's own Makefile should be the one to figure out what needs
updating and what doesn't.
Inline the recipe into the phony `git` rule.
|
|
Now that our tests don't depend on the `git` target anymore but instead
us the bin-wrappers we can drop the default installation prefix of the
`git` target. Instead, we'll now set it up the same as the `PREFIX` by
default but keep it overridable. This both simplifies the logic we have
where we don't need to remove the default prefix anymore, but it also
causes us to pay proper attention to the `PREFIX` variable by default
when we install Git.
While the `GIT_PREFIX` variable is essentially useless now we still keep
it to remain compatible with existing calling conventions.
|
|
We don't need to have a complete Git distribution installed in order for
out tests to work. Instead, we can simply use Git's own bin-wrappers to
avoid installing the complete Git distribution so that we only have to
build the binaries.
Do so and convert our tests to only build the Git distribution without
installing it. This let's us get rid of the default Git installation we
always do when we execute tests and thus allows us to simplify the
target to install the Git distribution.
|
|
We currently have a single target that's being used to both build and
install Git into the target location. While this target is used for
dependents to install a Git distribution via `make git GIT_PREFIX=...`,
it's also used as part of our tests to install into our own default Git
prefix so that we can set up the Git command factory correctly.
While the former use of this rule makes sense, it doesn't feel sensible
to require a complete installation for our tests. Let's prepare for a
fix to this by splitting up the rule into two: one to install a Git
distribution and one to build Git.
|
|
We're about to stop installing Git into our current default location.
Instead, tests are supposed to use the binary wrappers provided by the
Git project so that we don't have to install it in the first place.
Adapt the test-boot script to use them.
|
|
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.
|