| Age | Commit message (Collapse) | Author |
|---|
|
While it makes sense for tests to skip repository creation via the
`CreateRepository()` RPC when they are not testing in a context where
they have a gRPC server available, there should in the general case not
be a reason to skip this in our service-related tests. There still is a
bunch of tests that do this though.
Adjust the tests to not skip the RPC calls to create the repository and
refactor some that didn't make the server address available via the
Gitaly configuration. Note that we need to some touch up some tests
which erroneously created the repository multiple times, which would now
fail with Praefect.
|
|
Consolidate the unused InitRepo and CloneRepo functions. All existing
callers are using CreateRepository with `SkipCreationViaService` set to
`true.
|
|
Convert all callers of CloneRepo to use CreateRepository.
|
|
Convert all callers of InitRepo to use CreateRepository.
|
|
We have two sets of functions to create repositories for testing
purposes:
- CreateRepository creates the repository by calling the respective
RPCs of the RepositoryService. This allows us to properly test
with Praefect as a proxy, which requires the RPC to be called so
that it can set up the repositories in the database.
- InitRepo and CloneRepo, which both will create the repository
without doing an RPC call. These should only be used in contexts
where we don't have a gRPC service available.
It's confusing at times which of both should be used, and we're not
quite consistent.
Unify all functionality to create repositories into CreateRepository and
add a new option `SkipCreationViaService`. If set, this will behave the
same as InitRepo and CloneRepo, which allows us to consolidate the
functions into a single one. Callers that want to skip creation via the
RepositoryService will thus need to explicitly opt-in to this behaviour
and cannot just use InitRepo respectively CloneRepo without knowing
about the ramifications.
|
|
'4257-usermergebranch-does-not-verify-it-got-a-user-name-and-email' into 'master'
usermergebranch: add validation for user.{email, name}
Closes #4257
See merge request gitlab-org/gitaly!4800
|
|
operations: Convert test hooks to use Bash instead of Ruby
See merge request gitlab-org/gitaly!4803
|
|
While 'UserMergeBranch' verifies that it got a user as part of the first
request, it doesn't verify that the user actually has a name and email
set. This leads to an Internal error at a later point when trying to
create the merge commit because you cannot create merge commits with
either of them being empty.
This commit improves our validation to check these parameters and return
an InvalidArgument error if unset. We add a new test
'TestUserMergeBranch_failure' to test the validation logic in
'UserMergeBranch'.
Signed-off-by: Karthik Nayak <knayak@gitlab.com>
|
|
As we're progressing with out conversion of Ruby-based code we're
drawing ever closer to a future where there is no Ruby in Gitaly's code
base anymore. Some of our tests still depend on Ruby though because they
use a set of custom hooks that are implemented in it.
Refactor these scripts to use Bash instead of Ruby. This requires less
boilerplate code and gets rid of the last set of custom hooks in our
tests that use Ruby.
|
|
One of our tests for gitaly-hooks asserts that both the command line
arguments and environment seen by the process match our expectations.
This is done by writing some custom hooks, where one of the hooks is
currently written in Ruby.
Refactor the hook to use Bash instead in order to reduce our reliance on
Ruby. While at it, convert the test to use `gittest.InitRepo()` instead
of `gittest.InitRepo()`: we don't depend on any references or objects
anyway, so there is not much of a point to use a completely seeded
repository.
|
|
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.
|
