| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[ci skip]
|
|
replication: Graceful stop of the replication processing loop
Closes #2703
See merge request gitlab-org/gitaly!3885
|
|
[ci skip]
|
|
updateref: Always assert state transitions if Git supports flushing
Closes #3781
See merge request gitlab-org/gitaly!3904
|
|
Add FetchBundle RPC
See merge request gitlab-org/gitaly!3808
|
|
'qmnguyen0711/1278-add-half-close-capability-to-gitaly-sidechannel' into 'master'
Add half-close capability to Gitaly sidechannel
See merge request gitlab-org/gitaly!3854
|
|
operations: Always return structured errors from Git2Go merges
Closes #3756
See merge request gitlab-org/gitaly!3896
|
|
FetchBundle copies the bundle stream to a tempfile that is then passed
to `git-fetch`.
Changelog: added
|
|
Since fetching without transactions should be the exception, we make the
default to fetch with transactions.
|
|
During the test setup we need only a single database
for the test to be created. As it uses transactions with
rollback action at the end of the test we don't need
to cleanup any changes done during the test execution.
|
|
The ReplicationEventQueueInterceptor interface is not used in
the production code as well as it's single implementation.
That change simplifies it by removing the interface and making
interceptor a testing entity. Now it tracks input and output
parameters used in methods calls. Now they can be used for
verification in the tests. The test code is simplified as well
because of the new Wait method on the interceptor. The call sites
now simplified based on this new additions.
|
|
The loop for processing replication events uses a root context
of the application. Once the context is cancelled in-flight
operation would be cancelled as well (network call, db operation,
etc.). Instead we should allow operation to complete and
stop processing events on the next iteration. It makes execution
of the replication events more stable and deterministic.
Closes: https://gitlab.com/gitlab-org/gitaly/-/issues/2703
Changelog: Fixed
|
|
The cleanup returned by the runPraefectServer reads for an error
from the channel. If it is run multiple times it blocks on the
second run as it doesn't receive data from the channel. As
there is only a single send to the channel and no one sends anything
else into it we close the channel. With that we can call for
cleanup function multiple times without issues.
|
|
updateref: Fix test flakiness when writing to updater fails
See merge request gitlab-org/gitaly!3899
|
|
Issue: https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1278
Changelog: added
|
|
Remove orphaned worktree directories
See merge request gitlab-org/gitaly!3889
|
|
repository: Always lock gitconfig and gitattributes on write
Closes #3764
See merge request gitlab-org/gitaly!3891
|
|
With 4abf27024 (updateref: Fix indeterminate state when locking refs,
2021-09-13), we have introduced proper verification of state transitions
in git-update-ref(1) such that we notice early on when locking of refs
fails. As a result, we won't try to vote on transactions where we could
have already known that git-update-ref(1) failed to lock refs in the
first place and would thus abort early on.
Remove the feature flag guarding this code. Given that this requires
changes in Git, we still need to verify that the current Git version
supports flushing of status updates.
|
|
Unrevert RepositoryExists interceptor changes
See merge request gitlab-org/gitaly!3887
|
|
The `Set()` function sets config entries in the gitconfig, but without
proper atomic guarantees. Given that it has since been replaced with the
`localrepo.SetConfig()` function, which does provide those guarantees,
the old function shouldn't be used anymore.
Remove it and remaining callers in tests.
|
|
We used to directly write to both the gitconfig and gitattributes files
without having proper locking semantics which assert that there was no
concurrent write to the same file. As a result, it could be that
multiple RPCs which modify the same file all succeeded, but overwrote
their respective changes.
This was fixed via a new locking file writer, which locks the file,
votes on the changes and then commits it into place only if all nodes
agree on the change and if there was no concurrent write to the same
file. Like this, we now have atomic guarantees on both the gitconfig and
gitattributes files.
Remove the feature flag which guards this code. It has been tested in
production without any observed issues.
Changelog: fixed
|
|
Revert catfile cache refactor
See merge request gitlab-org/gitaly!3902
|
|
FetchBundle will allow updating an existing repository with the objects
and refs of a bundle, such as an incremental backup. Right now the only
other RPC is `CreateRespositoryFromBundle` but this requires the
repository to not already exist. For incremental backups, there will be
a series of bundles that need to be applied to a repository in a
specific order.
|
|
`require.NoFileExists` specifically checks for files. It does not
consider directories files, so these tests were not working as expected.
|
|
When cleanup encounters a stale worktree directory it attempts to remove
it using `git worktree remove`. This however fails when there is a
directory that git does not know about.
It is not entirely clear how this situation arises but since this
directory is gitaly controlled and `CreateBundle` calls cleanup and this
is required by backups, we should attempt to remove any such orphaned
directories instead of erroring.
Changelog: fixed
|
|
[ci skip]
|
|
go 1.16 deprecated the ioutil package.
|
|
This reverts https://gitlab.com/gitlab-org/gitaly/-/merge_requests/3853
since we believe it's leading to a Goroutine leak in
https://gitlab.com/gitlab-com/gl-infra/production/-/issues/5566.
|
|
lint: Remove SA1019 exclude rules
See merge request gitlab-org/gitaly!3881
|
|
In one of our tests for the updateref package, we verify that we get an
error when trying to commit a change on a transaction that has already
been prepared. The test is flaky though given that it sometimes does not
return the expected error message from git-update-ref(1). This race is
caused by git-update-ref(1) exiting before we get to the point where we
can write another status change command to its stdin, and as a result we
get a failure writing to the command's pipe instead of the expected
error.
Fix this bug by explicitly cancelling the command and including its
stderr when writing to it fails. This makes sure that stderr was flushed
and we've got it available, and it would also include the error message
we are searching for in the test.
|
|
test: Fix data race on the votes counter
See merge request gitlab-org/gitaly!3897
|
|
The local variable votes used inside the transaction server
and in the test to verify amount of votes executed.
As code is executed in different goroutines we need to
protect access to the shared variable or use atomic instructions
to prevent data races.
|
|
ref: Drop ListNewBlobs RPC
See merge request gitlab-org/gitaly!3893
|
|
[ci skip]
|
|
repository: Remove `IsSquashInProgress()` RPC
Closes #3728
See merge request gitlab-org/gitaly!3892
|
|
In release 14.2, we have converted `UserSquash()` to never use worktrees
anymore. As a result, the old `IsSquashInProgress()` RPC doesn't really
do anything anymore and always returns the equivalent of `false`.
Upstream has thus been converted in b5b78c33c9f (merge_request: Drop
checks whether a squash is in progress, 2021-08-20) to not use the RPC
anymore, leaving it without callers.
Remove `IsSquashInProgress()`.
Changelog: removed
|
|
Remove SetConfig and DeleteConfig RPCs
Closes #3722
See merge request gitlab-org/gitaly!3890
|
|
In commit 84bd2721e (gitaly-git2go: Return structured conflict error on
merge conflict, 2021-08-26), we have changed gitaly-git2go's merge
subcommand to support structured errors. This allows us to return more
information why a merge failed, e.g. by returning the set of conflicting
files to the caller.
Drop the feature flag which guards this code and thus always enable the
use of structured errors.
|
|
The `ListNewBlobs()` RPC call has been replaced by the more flexible
alternative `ListBlobs()`, which can do the same but across multiple new
refs at once. The last callsite in Rails has been removed in 0bc19a62ac3
(gitaly_client: Remove unused `#list_new_blobs` function, 2021-09-15),
so it is not used anywhere anymore.
Remove the RPC call.
Changelog: deprecated
|
