| Age | Commit message (Collapse) | Author |
|---|
|
We have recently rewritten the way our Protobuf Gem is generated. As
part of that rewrite we have removed all generated Protobuf code from
our codebase as it is not needed anymore and instead generated ad-hoc
when building the Gem.
Part of this generated code is also `version.rb`, which contains the
current Gitaly version. This file is being written by the Release tools
bot when tagging a new release, but it is not really required as the
same version is also present in our `VERSION` file. We thus also started
to generate this file by seeding it with the contents of our `VERSION`
and have subsequently removed it from our tree in 326913168 (ruby:
Remove stale generated Protobuf code, 2022-10-27).
Given that the Release tools bot hasn't yet been upgraded though to stop
writing this file it was reintroduced in a later commit. The change to
the bot has since landed though, which effectively means that the file
is now stale and won't ever be updated anymore. So let's remove it.
|
|
[ci skip]
|
|
[ci skip]
|
|
Now that we stopped updating our Ruby code generated from the Protobuf
definitions in favor of ad-hoc generating it when building a new Gem it
does not make sense to carry these files around anymore:
- They are stale and will not be updated anymore.
- Most of these files are unused anyway.
- It is not expected that there will be any changes in the generated
code that is relevant to our Ruby sidecar anymore. There is only a
single RPC served by it nowadays which is in the process of being
migrated to Go.
Remove the Protobuf definitions and use the `gitaly` Gem instead.
|
|
On every version bump the GitLab Release Tools bot updates the version
in two different files: first in our top-level `VERSION` file, and
second in the Ruby Protobuf files at `ruby/proto/version.rb`. Both files
basically contain the same information, but serve different purposes.
We're about to drop our generated Ruby Protobuf code though in favor of
creating the Protobuf Gem ad-hoc. This also means it doesn't make a
whole lot of sense anymore to carry around the version file in our tree.
Consequentially, we've adjusted the Release Tools bot to stop writing
the `version.rb` file completely. Instead, we now generate the file via
the information we already have in our `VERSION` file.
|
|
The README file located with our generated Ruby Protobuf code still
provides information of the old times where Protobuf definitions were
living in their own `gitaly-proto` repository. These times have long
gone by, and I doubt anybody still tries to search for that repository.
Remove the README. This also prepares for us dropping the generated Ruby
code from our tree altogether.
|
|
In a prior MR, all Wiki-related RPCs are removed from Gitaly,
all the corresponding code paths in Ruby are redundant. This
commit targets removing Wiki handlers inside ruby sidecar, Wiki
protobuf definition, and gollum gems. The rugged gem is
intentionally left out for the next MR to reduce the change size.
Issue: https://gitlab.com/gitlab-org/gitaly/-/issues/4513
Changelog: removed
|
|
Add a new `UserCommitFilesError` message type that will be used to add
structured errors to the `UserCommitFiles` RPC. This necessitates
creating a new `IndexError` error type to enumerates the type of index
operations that may fail.
We limit `IndexError` to a single path despite a potentially large
number of files being modified because we end the RPC on the first
failure, so any subsequent paths that would have failed are not
encountered. `path` is sent as `bytes` in the proto because file paths
are not guaranteed to be valid UTF-8 by many common filesytems, which is
the required encoding for protobuf strings.
|
|
In the current implementation of SearchFilesByName RPC, all matched
files are returned back. In most cases, clients don't need all of them.
Instead, they perform pagination at their side. It makes sense to add
pagination from Gitaly side so that this RPC returns a reasonable subset
of files. This improvement would remove redundant payload in the
response.
To keep backward-compatibility, Gitaly doesn't enforce default limit or
offset. It's client's call.
Issue: https://gitlab.com/gitlab-org/gitaly/-/issues/4449
Changelog: added
|
|
[ci skip]
|
|
'master'
Convert UserCreateBranch to use structured errors
Closes #4227
See merge request gitlab-org/gitaly!4835
|
|
proto: return 'Branch' in 'FindLocalBranchesResponse'
See merge request gitlab-org/gitaly!4842
|
|
Add a new message type `UserCreateBranchError`, which will be used to
provide structured errors for the `UserCreateBranch` RPC. This will be
released behind a feature flag.
Currently this structure only holds a single data type within it, i.e.
`CustomHookError`. Potentially can be extended in the future.
Run `make proto` to generate the related proto files from this.
Signed-off-by: Karthik Nayak <knayak@gitlab.com>
|
|
Currently 'FindLocalBranchesResponse' contains 'FindLocalBranchResponse'
which is a custom type drawn over the common 'Branch' type. In due of
deprecating the old and keeping type consistency we introduce
'local_branches' as a new field of type 'Branch'.
In subsequent releases we will deprecate the old
'FindLocalBranchResponse' from 'FindLocalBranchesResponse' and only keep
'Branch' type in it.
|
|
The field is removed as it was deprecated in 8f9dd5ab5
(proto: Introduce drift_threshold to replace
drift_threshold_millis, 2022-08-05) and not used anymore.
Closes: https://gitlab.com/gitlab-org/gitaly/-/issues/4417
|
|
[ci skip]
|
|
Gitaly uses the Licensee gem to find the license used in a
repository and return the corresponding license identifier
to GitLab. GitLab uses the same Licensee gem to get additional
info about the license using the identifier to show it on
the UI. Go and Ruby implementations of the FindLicense RPC
rely on different algorithms for license detection and the
set of licenses that could be detected are different as well,
that is why they are not fully compatible. Let's extend
FindLicenseResponse with additional fields, so GitLab
doesn't need to get that info from the Licensee gem anymore.
It solves the problem of the compatibility of the two
implementations.
Part of: https://gitlab.com/gitlab-org/gitaly/-/issues/3782
|
|
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
|
|
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
|
|
[ci skip]
|
|
The new ReadinessCheck RPC added. It will allow to check the
service readiness and should be triggered before putting traffic
on to the service. In case of the failure the details about an
error and the check name would be returned to the caller.
Part of: https://gitlab.com/gitlab-org/gitlab/-/issues/348174
|
|
We can extract which reference caused an error. Add Ref field to
ReferencesLockedError so we can pass this information back to the
caller.
|
|
[ci skip]
|
|
proto: Fix definition of FindTagError
See merge request gitlab-org/gitaly!4770
|
|
The definition of the FindTagError we have just introduced in c6e1eb148
(proto: Introduce FindTagError to distinguish non-existent tags,
2022-07-29) was mistakenly missing the `oneof` definition. The error is
not yet used by anything, so let's correct it before we do grow any
callers.
|
|
objectpool: Fix conflicting references when fetching into pools
Closes #4373
See merge request gitlab-org/gitaly!4745
|
|
[ci skip]
|
|
When the FindTag RPC is invoked with a tag that doesn't exist then we
return an `Internal` gRPC error. This is clearly not ideal given that
those errors count against our SLOs, and furthermore it's an expected
error condition to say that a tag does not exist. We should thus slap on
a proper error code in that condition.
This raises an issue in the Rails codebase though because the `NotFound`
code is typically used to indicate a missing repository. So if we now
also start to retrun `NotFound` for missing tags then it's hard for
Rails to distinguish those two error conditions without matching the
error's message.
To fix this issue we introduce a structured error that gives the caller
a clear indication that the reference was indeed not found so that they
can distinguish those two conditions.
|
|
The FindTag RPC does not have any documentation right now. Add some.
|
|
The `FetchIntoObjectPoolRequest` messages has a `Repack` field that
supposedly controls whether the repository should or should not be
repacked. This flag is completely ignored though and has always been
ignored. It also isn't ever set by the Rails client.
Remove the field without replacement for the time being. It seems like
there is no usecase for it right now and it's bad to keep a no-op flag
around in our code. Furthermore, we will want to fully move repository
housekeeping into Gitaly eventually anyway.
|
|
Add missing documentation for the FetchIntoObjectPool RPC.
|
|
[ci skip]
|
|
operations: Preparatory refactorings for UserCreateTag
See merge request gitlab-org/gitaly!4740
|
|
Improve the documentation for our Protobuf definitions of
UserCreateTags.
|
|
Introduce a structured UserCreateTagError that can be returned by the
UserCreateTag RPC. This will eventually replace error conditions where
we're currently failing to create the tag, but return successfully
anyway.
In order to demonstrate that this structured error covers all cases we
care about this commit also adds comments to all current sites where we
return success under an error condition.
Changelog: added
|
|
|
|
linguist: Implement Stats in pure Go
See merge request gitlab-org/gitaly!4580
|
|
[ci skip]
|
|
We're about to make some changes in the handling of the CommitLanguages
rpc, and because I noticed this RPC did not have any documentation, I've
decided to add it.
|
|
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
|
|
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
|
