This project is mirrored from https://gitlab.com/gitlab-org/gitaly.git.
Pull mirroring updated .
- Aug 14, 2022
-
-
Stan Hu authored
This matches the versions used in GitLab Rails and helps reduce some space in the Omnibus build. Changelog: changed
-
- Aug 12, 2022
-
-
Toon Claes authored
Default enable Praefect generated replica paths See merge request gitlab-org/gitaly!4809
-
Toon Claes authored
fsck: Update fsck ignore rules configuration Closes #4265 and #4404 See merge request gitlab-org/gitaly!4777
-
- Aug 11, 2022
-
-
Justin Tobler authored
Added tests to ensure correct configuration of git-fsck(1) is generated and applied to the command when executed.
-
Justin Tobler authored
Currently fsck ignore rules configuration only applies to git-fetch-pack(1) and git-receive-pack(1) commands. These rules should also apply to the git-fsck(1) command itself. This change unifies the configuration.
-
John Cai authored
Use semantic sort for tags See merge request gitlab-org/gitaly!4336
-
Toon Claes authored
Remove default MR template See merge request gitlab-org/gitaly!4811
-
John Cai authored
The default MR template creates unnecessary work since we already take pains to write a coherent and detailed commit message. Once the MR template supports automatic importing of commit messages, we can add a default template once again.
-
Patrick Steinhardt authored
golangci-lint: Add the `thelper` linter to enforce more-consistent test style See merge request gitlab-org/gitaly!4806
-
Patrick Steinhardt authored
The `thelper` linter has a rule that will flag test helper functions that don't call `t.Helper()`. Unfortunately, this will also flag all kinds of functions that really shouldn't have this call, which makes the linter effectively useless for us. Document why we disable it to not keep folks wondering.
-
Vasilii Iakliushin authored
Contributes to https://gitlab.com/gitlab-org/gitlab/-/issues/17801 **Problem** Default sort by name for tags often does not produce the expected result. ``` v1.1.0 v1.10.0 v1.2.0 ``` **Solution** Use semantic sort for tag names ``` v1.1.0 v1.2.0 v1.10.0 ``` Changelog: changed
-
Patrick Steinhardt authored
Enforce consistent naming of `testing.TB` variables, which should be called `tb`, and adapt tests that violate this rule.
-
Patrick Steinhardt authored
Enforce that `testing.T` et al must be the first parameter of test functions. Unfortuntately, the linter explicitly allows for contexts to precede `testing.T`, which causes us to still not enforce a uniform style for our test functions. Fix cases where we violate this rule.
-
Patrick Steinhardt authored
Add the `thelper` linter, which knows to enforce consistent code styles around tests: - `testing.T` should be the first parameter in test-related functions. - Functions called by tests should call `t.Helper()`. - `testing.T`, `testing.B` and testing.TB` variables should be consistently named as `t`, `b`, and `tb`, respectively. Right now we still have all rules disabled that would trigger warnings.
-
Patrick Steinhardt authored
We currently exclude a revive rule that `context.Context` should be the first parameter for our test sources. This can be handled better though because golangci-lint allows us to exclude certain types from this rule. Adapt the rule to allow `testing.T` et al before `context.Context` and remove the excluded rule. Interestingly, this now surfaces a whole bunch of `nolint: revive` annotations that aren't needed anymore, so we fix them in the same commit.
-
Patrick Steinhardt authored
Update golangci-lint to v1.48.0 and fix two warnings it starts to surface due to that update.
-
Patrick Steinhardt authored
gittest: Consolidate functions to create test repositories See merge request gitlab-org/gitaly!4795
-
Pavlo Strokov authored
git: Fix warning on startup about Git binary fallback See merge request gitlab-org/gitaly!4805
-
Sami Hiltunen authored
This commit default enables Praefect generated replica paths feature flag. The feature flag has been enabled on production since 2022-07-25. The changes have been exercised on GitLab.com with new repositories that are mainly forks of GitLab projects that live on the Gitaly Cluster. There have been no reports of issues and the logs don't surface anything that seems problematic. Changelog: changed
-
Patrick Steinhardt authored
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.
-
Patrick Steinhardt authored
Consolidate the unused InitRepo and CloneRepo functions. All existing callers are using CreateRepository with `SkipCreationViaService` set to `true.
-
Patrick Steinhardt authored
Convert all callers of CloneRepo to use CreateRepository.
-
Patrick Steinhardt authored
Convert all callers of InitRepo to use CreateRepository.
-
Patrick Steinhardt authored
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.
-
Sami Hiltunen authored
objectpool: Default-enable pruning of refs to fix reference conflicts See merge request gitlab-org/gitaly!4807
-
- Aug 10, 2022
-
-
John Cai authored
limithandler: Remove RateLimiting feature flag See merge request gitlab-org/gitaly!4796
-
Toon Claes authored
usermergebranch: add validation for user.{email, name} Closes #4257 See merge request gitlab-org/gitaly!4800
-
Patrick Steinhardt authored
operations: Convert test hooks to use Bash instead of Ruby See merge request gitlab-org/gitaly!4803
-
Patrick Steinhardt authored
In 018958fb (objectpool: Fix conflicting references when fetching into pools, 2022-07-27) we have introduced the logic to enable pruning of references when we update an object pool via FetchIntoObjectPool. This change was required because we have seen cases where updating object pools continued to fail due to conflicting references which exist in the pool repository and the member we have been fetching from. By pruning any references which don't exist in the member anymore we were able to resolve these conflicts and thus this bug. This change has been rolled out to production on August 3rd without any observed issues. So let's default-enable the feature flag guarding this code so that the fix will be included in the next release. Changelog: fixed
-
Karthik Nayak authored
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>
-
Patrick Steinhardt authored
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
-
Patrick Steinhardt authored
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.
-
Patrick Steinhardt authored
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.
-
- Aug 09, 2022
-
-
Pavlo Strokov authored
server: Introduce drift_threshold with proper type to replace drift_threshold_millis Closes #4412 See merge request gitlab-org/gitaly!4788
-
Pavlo Strokov authored
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
-
Pavlo Strokov authored
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
-
Toon Claes authored
linguist: Ensure empty files are omitted in totals Closes #4416 See merge request gitlab-org/gitaly!4791
-
Toon Claes authored
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.
-
Toon Claes authored
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
-
Toon Claes authored
The ByteCountPerLanguage type is equal to map[string]uint64, so use the type definition instead.
-