| Age | Commit message (Collapse) | Author |
|---|
|
Our build process never cleans up the go build cache and neither does
go. Users are expected to run `go clean --cache` occassionally to
clean up old files. This has so far been generally fine, given each
build didn't bloat the cache too much. With the introduction of
packed binaries in 861730ac, the build cache grows at a much higher
rate due to the embedded binaries. This has resulted the CI also
running out of space. This commit adds a configurable threshold for
cleaning up Go's build cache and sets the default at 5 GB. If the
build cache is larger than 5GB at the beginning of the build, the
build cache is automatically cleaned.
|
|
Remove legacy go.mod and go.sum files from _build directory
Closes #4381
See merge request gitlab-org/gitaly!4758
|
|
Bump all Rails-related gems to v6.1.6.1
See merge request gitlab-org/gitaly!4759
|
|
gittest: Refactorings to make the package hash-clean
See merge request gitlab-org/gitaly!4734
|
|
Clarify max_queue_size is per RPC, not project
See merge request gitlab-org/gitaly!4753
|
|
All versions should have been bumped in unison since they are released
at the same time, and this change mirrors the GitLab Rails changes in
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92400.
Changelog: changed
|
|
The build process left a go.mod and go.sum file in the _build directory
in the past. This causes problems these days when attempting to embed
the auxiliary binaries into Gitaly binary as they are considered to be
in a different module due to this. Remove the legacy files prior to
building Gitaly.
|
|
operations: Remove CherryPickStructuredErrors feature flag
See merge request gitlab-org/gitaly!4747
|
|
Makefile: Add section for environment variables
See merge request gitlab-org/gitaly!4737
|
|
Remove 'exact_pagination_token_match' feature flag
See merge request gitlab-org/gitaly!4724
|
|
Fixes for a range of typos
See merge request gitlab-org/gitaly!4751
|
|
|
|
|
|
|
|
|
|
operations: Remove UserRebaseConfirmableImprovedErrorHandling FF
See merge request gitlab-org/gitaly!4746
|
|
ruby: Fix dependencies in Gemfile.lock
See merge request gitlab-org/gitaly!4750
|
|
With 4da75e5814680fe0d657bb734099527c74b76905 we attempted to update
actionview to resolve a security issue. However, in doing so we updated
the version of actionpack and its dependencies, but not actionview
itself. This has led to builds emitting the following warning:
Your lockfile doesn't include a valid resolution.
You can fix this by regenerating your lockfile or trying to manually editing the bad locked gems to a version that satisfies all dependencies.
The unmet dependencies are:
* actionview (= 6.1.5.1), depended upon actionpack-6.1.5.1, unsatisfied by actionview-6.1.4.7
* activesupport (= 6.1.5.1), depended upon actionpack-6.1.5.1, unsatisfied by activesupport-6.1.4.7
Update Gemfile.lock to update all related dependencies to matched
versions and stop this error.
|
|
Update the stage label to systems for danger
See merge request gitlab-org/gitaly!4748
|
|
|
|
Now that we have been running this feature flag in production for a week
without issue, we can remove it.
|
|
GIT_VERSION can be set to, for instance, run tests with a specific git
version. Add a section to `make help` to display this.
|
|
Now that the UserRebaseConfirmable has been on in production without
issues, we can remove the feature flag.
|
|
git: Don't advertise internal references via git-upload-pack(1)
Closes #4358
See merge request gitlab-org/gitaly!4727
|
|
Gemfile.lock: Update actionview gem
See merge request gitlab-org/gitaly!4739
|
|
ssh: Improve errors for fetches canceled by the user
Closes #4331
See merge request gitlab-org/gitaly!4731
|
|
|
|
|
|
In recent weeks we have started to see an uptick of incidents caused by
a single user that was repeatedly fetching from a specific repository
via the SSHUploadPackWithSidechannel RPC. The error has always been the
same:
fatal: the remote hung up unexpectedly
This error is returned by git-upload-pack(1) in case it sees a short
read of data and ultimately indicates that the user has probably killed
git-fetch(1). This is not an actionable error on our side as it is a
totally expected outcome that a killed fetch will cause the fetch to
fail.
Now that we have a lot more tests in this area we can be reasonably sure
that short reads on an otherwise normally closed network connection is
seemingly the only condition that causes the above error. So let's put a
gRPC error code of `Canceled` on this error so that it doesn't cause our
alerts to go off anymore.
Changelog: fixed
|
|
Unfortunately, the test added by that commit is flaky. And while I could
drop that commit before we merge this patch series I think that the
logic added in there is interesting enough to keep around for future
reference if we ever wanted to revisit this topic. Also, even though
it's flaky, it still served its purpose to demonstrate it is fine to
wrap errors with an `Canceled` gRPC code in case we see "fatal: the
remote side hung up unexpectedly".
So let's just keep this commit in our history and revert it.
|
|
In gitlab.com there has been a recent uptick in incidents caused by
SSHUploadPackWithSidechannel failing with the following error message:
fatal: the remote end hung up unexpectedly
While we have been reasonably sure that this error really only happens
in case the client has cancelled the fetch, we couldn't really tell
whether any other conditions might trigger the same error. Most notably,
we were not sure if this might've indicated network connectivity issues.
Add tests to exercise this RPC call with injected network errors. As it
turns out, none of the injected errors cause the error to appear, which
is a good thing.
|
|
Add two more tests that verify reference negotiation with invalid and
missing objects fails as expected.
|
|
The testhelper to start the gRPC server for the ssh service is only
exposing the socket address of the server. Add a new function that
returns the `GitalyServer` to make it accessible to tests.
|
|
Make the gRPC server accessible to outside callers so that they can for
example register additional listeners for the server.
|
|
Add a function to format gRPC errors with an error code of `Canceled`.
|
|
|
|
Revert "Change FindTag err when tag not found to NotFound"
See merge request gitlab-org/gitaly!4736
|
|
This reverts merge request !4735
|
|
[ci skip]
|
|
'4366-findtag-returns-an-internal-error-code-when-it-cannot-find-a-specific-tag' into 'master'
Change FindTag err when tag not found to NotFound
Closes #4366
See merge request gitlab-org/gitaly!4735
|
|
What
---
Update the error message to be `Not Found` rather then `Internal` when a
tag is not found.
Why
---
We burn through our error budget when a single user sends a bunch of
requests to tags that don't exist because we classify the error as
`Internal`, instead it should be `NotFound`.
Reference: https://gitlab.com/gitlab-org/gitaly/-/issues/4366
Signed-off-by: Steve Azzopardi <sazzopardi@gitlab.com>
|
|
Enable testing of the gittest package against SHA256 by removing the
build tags.
|
|
Refactor both RequireTree and the WriteTree tests to both be hash-clean
so that they work with SHA1 and SHA256. Note that we're also dropping
the expected object hash from our tests: we already verify that tree
entries match, so it doesn't feel sensible to check this opaque hash in
the first place.
|
|
Expose the hash function used by our different object hash
implementations so that we can both learn about the hash size and
compute our own object hashes in tests.
Note that this makes it impossible to compare the structure anymore due
to the added function pointers. We thus have to adjust a small set of
sites to not do that anymore.
|
|
The gittest package is still hardcoding the use of SHA1 in a small set
of places. Refactor the code to instead use the default object hash.
|
|
We're currently using one of our seed repositories as default repo in
our gittest tests. Because this seed repository is using SHA1 as the
object hash this renders us unable to actually test against both SHA1
and SHA256.
Convert the setup to instead use an empty repository. Tests should just
create their required data at runtime.
|
|
Refactor the tests for WriteCommit to be object hash-agnostic.
|
|
When not explicitly given a set of parents in WriteCommit, then we fall
back to using a well-known commit in our default seed repository. This
may both be unexpected and makes it needlessly complex to use this
function in an empty repository.
Drop the fallback logic and create commits without any parents if not
asked to do so.
|
|
We're currently distributing the knowledge around the default committer
information all over the test suite. This makes it hard to change
eventually.
Introduce a set of constants that keep this information readily
available for use in our tests.
|
|
It's not currently possible to use our test repositories in combination
with SHA256 given that they're all using SHA1. This makes it easy to
accidentally test with SHA1 even though one thought to be testing with
SHA256.
Detect the use of seeded repositories and fail the test when done with
SHA256 is the default hash.
|
