| Age | Commit message (Collapse) | Author |
|---|
|
The structured `MergeConflictError` provides information about the files
that have been conflicting, but it doesn't provide any information about
the revisions that caused the merge conflict. While that info should in
the general case already be available on the calling-side, it may not
necessarily be in case the caller e.g. only specified branch names
instead of commit IDs.
Add a new `ConflictingCommitIDs` field to the message that contains the
object IDs of the conflicting commits to provide additional context.
|
|
This commit changes the major version in the package name from v14 to
v15
Updating go.mod & go.sum with new module name v15
Update Makefile to bump major version to v15
Update the gitaly package name in the Makefile. Also update
gitaly-git2go-v14 -> gitaly-git2go-v15. We need to keep
gitaly-git2go-v14 for a release however, for zero downtime upgrades.
This pulls directly from a sha that is v14.
Update package name from v14->v15 for auth, client, cmd, internal packages
This commit changes the package name from v14 to v15 in go and proto
files in the internal, auth, client, cmd packages.
proto: Update major package number in package name
tools: Change major version number in package name from v14 to v15
gitaly-git2go: Change the package name from v14 to v15
update module updater for v15
Update the documentation for the module updater to reflect v15
|
|
We want to return a structured error from DeleteRefs when certain errors
happen. Currently we are returning nil for the error, which leads to
unnecessary Praefect replication jobs.
|
|
Our error handling for custom hooks is extremely fragile: when a custom
hook returns a non-zero value, then we must make sure to pass either its
stderr or stdout to Rails as error message without any changes at all.
This is because Rails knows to check for a specific string prefix, and
if the error message has that prefix then the error is slated to be
displayed in the web interface. This means that we as Gitaly _must not_
change the error string at all.
Of course this has repeatedly been broken in the past, and is broken
right now once again. And that's not really surprising: no component of
the stack should rely on parsing exact error messages. Furthermore, any
error messages logged by Gitaly are ultimately not pointing to the real
location in our code, but may be an arbitrary user-controlled string and
thus ultimately not helpful.
Introduce a new detailed error type `CustomHookError` that allows us to
instead pass both standard output and standard error to the caller
without having to make any compromises on the error messages we
generate. Having this explicit calling interface makes it easy to see
for the caller what they may expect, it's hard for us to break, and also
extremely helps with regards to discoverability.
Changelog: added
|
|
proto: Add CherryPickError type for UserCherryPick structured errors
See merge request gitlab-org/gitaly!4497
|
|
In UserCherryPick, there are some error conditions where instead of
returning an error, we return OK and embed the error in the response.
Instead of doing this, we want to return structured errors.
This change adds the proto definition for this error.
|
|
|
|
When Gitaly enforces a limit, either due rate limiting or concurrency
limiting, it needs to be able to return an error to its clients to
provide context into why it failed so that clients can then inform its
callers of why the call failed.
Changelog: added
|
|
We're about to introduce support for structured errors in the UserSquash
RPC. We cannot roll out this change even with a feature flag though
because some of our testing infrastructure will always test code with
all feature flags enabled. We thus have to land the protobuf changes
independently such that we can adjust downstream callers.
This commit introduces these changes by creating a new UserSquashError
Protobuf message which contains all potential structured errors we want
to return from the UserSquash RPC.
Changelog: added
|
|
It is not possible for RPC clients to tell when RPCs have failed to
update a reference. Add a new error detail type which represents such
failures to prepare for passing down this information.
Changelog: added
|
|
When `UserMergeBranch` fails during hook execution, then we will not
cause the RPC to fail but instead embed the error in the response's
`PreReceiveError` field. This has led to quite some problems: Praefect
cannot determine failing RPC calls, we need to do weird games where we
need to make sure to pass through Rails' error messages verbosely, and
most importantly the upstream caller cannot easily deduce what really
has failed without comparing returned error messages. As a result, this
pattern which we use across many of our user-facing RPCs is quite
lacking.
To fix this, we can use gRPC's rich error model. This error model allows
us to embed arbitrary proto messages into the returned error, which
grants us the ability to return structured errors to the caller. Like
this, we can embed various information into errors in a structured way
which can then be extracted by upstream callers simply by unmarshalling
those error details.
Convert UserMergeBranch to use this rich error model as a proof concept.
For now, rich errors only include details in case the access checks help
to keep this change as focussed as possible. If this new model proves
viable, we may extend this to also include additional information in
different error cases, like for example the set of conflicting files in
case a merge fails.
Changelog: changed
|
