| Age | Commit message (Collapse) | Author |
|---|
|
Populating flat paths for large trees may be expensive
Let's add an option to skip it (to preserve the default behaviour)
in order to be able to avoid this expensive operation when it's
not necessary
Changelog: added
|
|
FullPath will allow fetching the value previously set by the SetFullPath
RPC. FullPath assists admins to determine which repo on disk is
associated with which repository on gitlab.
Changelog: added
|
|
operations: Always enable structured errors in UserDeleteBranch
Closes #4286
See merge request gitlab-org/gitaly!4660
|
|
The `PreReceiveError` field in the `UserDeleteBranchResponse` is never
set anymore in favor of the new structured errors. Mark the field as
deprecated.
|
|
git diff-tree outputs a line for each changed path that contains the
old and new Unix file modes of the path in octal format. Extract these
old and new modes and pass them in the FindChangedPaths RPC response.
|
|
FindChangedPaths: Add requests field
See merge request gitlab-org/gitaly!4597
|
|
Add glId, glUser, glRepo, glProtocol to PackObjectsRequest
See merge request gitlab-org/gitaly!4599
|
|
While we already handle some of the errors in UserMergeBranch specially
via structured errors, we don't yet do so for merge conflicts. Amend
this error handling so that callers can know that the error is indeed
caused by a merge conflict, and so that they can find our exactly which
files have been conflicting.
Note that this is not done behind a feature flag: there aren't any
callers which parse the error, and neither should there be any. So given
that we retain the same error code as before but only amend the error
message and add some error details this should not be a breaking change.
Changelog: added
|
|
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.
|
|
In order to get visibility into how pack object processes are spawned
concurrently, we plan to pass in information of the initiator of the
request into the pack objects hook's RPC method.
This commit adds the fields to the proto message definition.
|
|
This field is more advanced, and allows you to specify either two trees
or a commit and optional commits to treat as parents of the commit.
This change brings FindChangedPaths in line with the full capabilities
of git diff-tree. This also deprecates the commits field.
|
|
operations: Use structured errors in UserDeleteBranch
See merge request gitlab-org/gitaly!4605
|
|
operations: Remove deprecated error fields
See merge request gitlab-org/gitaly!4610
|
|
Update protoc to v21.1. Note that this is quite a jump from our current
v3.17.3. This isn't all that scary, but a result of upstream changing
their versioning schema to drop the leading `3`. Our generated Go files
remain unchanged.
|
|
Update protoc-gen-go-grpc to v1.2.0. The most notable change is that we
now have headers in our generated gRPC services that indicate the
versions used to generate them. Other than that there are no changes in
our generated files.
|
|
Update protoc-gen-go to v1.28.0. No noticable changes come with this
release, and most notably there are no changes in our generated Go
files.
|
|
UserDeleteBranch is returning successfully in some error cases. This is
a pattern we want to get rid of, so let's convert the RPC to instead use
the structured errors via the new `UserDeleteBranchError` message type.
This fixes some cases where we know to create replication jobs because
the `UserDeleteBranch` RPC returns successfully, but didn't cast a
single vote.
Changelog: fixed
|
|
The `GitError` field of the `UserSquash` response has been deprecated in
e8413304d (operations: Always use structured errors for UserSquash,
2022-03-21) and is never set anymore. Let's remove it.
|
|
The `PreReceiveError` field of the `UserMergeToRef` response has been
deprecated in 9aa0347a2 (proto: Deprecate PreReceiveError field in
UserMergeToRefResponse, 2022-03-07) and is never set anymore. Let's
remove it.
|
|
The `PreReceiveError` field of the `UserMergeBranch` response has been
deprecated in 151bdfd96 (proto: Deprecate PreReceiveError field in
UserMergeBranchResponse, 2022-03-07) and is never set anymore. Let's
remove it.
|
|
We're about to convert UserDeleteBranch to use structured errors. As a
first step we introduce a new UserDeleteBranchError message that hosts
all errors that are expected failures and which may thus be handled by
the client. The RPC is not yet converted to use the new error types
because we first have to update clients to handle them.
|
|
The UserDeleteBranch RPC is missing documentation. Add it to document
its behaviour and expected error cases.
|
|
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.
|
|
Extended ListCommits to support filter by commit message
See merge request gitlab-org/gitaly!4421
|
|
Now that we are trying to extend ListCommits rpc of CommitService to
include various cases. It's updated to include functionality provided
by CommitsByMessage rpc and also support regex ignore case flag.
Changelog: changed
|
|
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: Update documentation and modernize our style guide
See merge request gitlab-org/gitaly!4539
|
|
Use git2go merge for squashing
Closes gitlab#352581
See merge request gitlab-org/gitaly!4514
|
|
Our enumerations do not currently have any strict design guidelines.
This brings two issues with it:
1. Enumeration values are scoped per-service. Consequentially, if
two enumerations want to declare a value with the same name, the
declarations will clash.
2. It is not possible to discern the case where a caller hasn't set
the value of an enumeration at all versus the case where the
field was explicitly set to its zero-value.
The official Protobuf style guide thus says that enum values should
always be prefixed with the name of the enum itself, and that the zero
value should be called `UNSPECIFIED`. Let's enforce this style via
protolint so that any new enumerations will follow this recommendation.
|
|
Enforce that message fields must have a comment and add a placeholder
for all instances where such a comment is missing.
|
|
Enforce that enum fields must have a comment and add a placeholder for
all instances where such a comment is missing.
|
|
Enforce that enum definitions must have a comment and add a placeholder
for all instances where such a comment is missing.
|
|
Enforce that message definitions must have a comment and add a
placeholder for all instances where such a comment is missing.
|
|
Enforce that RPC definitions must have a comment and add a placeholder
for all instances where such a comment is missing.
|
|
The Protoc plugins we use are hidden away deep into the `proto/`
directory, which makes it very hard to discover them when one doesn't
already know about their existence. Let's move them into a new top-level
`tools/` directory.
|
|
There is no real reason why the `protoc-gen-gitaly-lint` package
requires another internal package to provide the actual logic.
Furthermore, we want to move this plugin into a top-level `tools`
directory to make it easier to discover.
Absorb the `linter` package to make it easier to move the code around.
|
|
The `protoc-gen-gitaly` plugin provides two different functionalities:
- It lints our Protobuf definitions to make sure they conform to our
coding guidelines.
- It generates a `protolist.go` file, which contains a list of all
Protobuf files.
This is conflating two otherwise unrelated concerns, and thus makes the
divide between our `proto` and `lint-proto` Makefile targets a bit
blurry. Furthermore, it is creating a cyclic dependency: the linting
logic requires that the Protobuf files must have already been generated,
but we can only generate them when we have plugin compiled.
Prepare for a fix by splitting up functionality of this plugin into two
separate plugins: `protoc-gen-gitaly-lint` is responsible for linting
our definitions, while `protoc-gen-gitaly-protolist` will generate the
list of Protobuf files.
|
|
When feature flag squash_using_merge is enabled, we are not
using rebase to merge. I'm clarifying it in the comment.
|
|
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.
|
|
commit: Various fixes for `CheckObjectsExist()`
See merge request gitlab-org/gitaly!4510
|
|
The `PackObjectsHook()` RPC is deprecated and its implementation has
been removed in 473e3540f (Deprecate PackObjectsHook, 2021-10-25).
Now that v15.0 is close, let's also remove the Protobuf definitions.
Changelog: removed
|
|
The `CheckObjectsExist()` RPC is a streaming RPC: the caller may send
one or more requests to check sets of revisions. This is done such that
this RPC call also works in the context where millions of revisions need
to be checked in a single call, which could otherwise exceed the gRPC
memory limitations.
The current behaviour is a tad weird though: revisions sent as part of
the initial request are completely ignored. This doesn't feel right as
the caller would now be forced to _always_ send at least two messages.
It's also not documented to be the case, and last but not least all our
other streaming RPCs don't do it this way either.
So let's fix this behaviour and also honor revisions sent of the initial
request.
Changelog: fixed
|
|
This makes the naming of all proto files consistent.
|
|
|
|
Fix typo in documentation of UserCommitFilesRequestHeader
See merge request gitlab-org/gitaly!4422
|
|
With the introduction of metadata verification, Praefect needs a tool
to manually mark a repository as needing verification immediately rather
than after the specified verification interval has passed. That tool will
require a new RPC that it can call achieve its goal. This commit adds the
proto definitions for MarkUnverified RPC which can be called to either
mark a single repository by ID, a whole virtual storage, or a whole storage
as needing verification.
Changelog: added
|
|
proto: Add LimitError as a structured error
See merge request gitlab-org/gitaly!4476
|
|
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
|
