| Age | Commit message (Collapse) | Author |
|---|
|
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 to v1.28.0. No noticable changes come with this
release, and most notably there are no changes in our generated Go
files.
|
|
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
|
|
Enforce that message fields 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.
|
|
|
|
|
|
The FetchInternalRemote RPC had been used internally to replicate
repositories across different Gitaly nodes. At some point in time, this
was converted to do a direct fetch though without an additional RPC call
because as it turned out, doing inter-Gitaly mutating RPC calls is
problematic in combination with transactions given that the remote side
would now try to cast votes against another Gitaly. Nowadays, there are
no callers left which use this RPC.
Remove the deprecated `FetchInternalRemote()` call. The backing logic
which is still internally called remains though for use in other parts
of Gitaly. We may eventually want to find a better place for it to live.
Changelog: removed
|
|
The FetchInternalRemote RPC isn't used by anything anymore. Let's
deprecate it such that we can remove it in the next release.
Changelog: deprecation
|
|
The ListRemotes RPC call has already been removed quite a while ago, but
its messages were not cleaned up back then. Remove them now.
|
|
On-disk remotes have been deprecated, and no upstream callers remain
which use them anymore. Remove support for them in FindRemoteRootRef by
dropping the "remote" parameter.
Changelog: removed
|
|
On-disk remotes have been deprecated, and no upstream callers remain
which use them anymore. Remove support for them in UpdateRemoteMirror by
dropping the "ref_name" parameter from the request. Note that "ref_name"
was misnamed and really was the remote that should have been fetched.
Changelog: removed
|
|
On-disk remotes have been deprecated, and no upstream callers remain
which use them anymore. Remove the `AddRemote()` RPC and rename the file
where it had been previously contained in to "find_remote_repository.go"
after the only remaining RPC in there.
Changelog: removed
|
|
On-disk remotes have been deprecated, and no upstream callers remain
which use them anymore. Remove the `RemoveRemote()` RPC.
Changelog: removed
|
|
|
|
As we're about to phase out usage of on-disk remotes, all RPCs which
interact with them need to be converted to use in-memory remotes.
`UpdateRemoteMirror()` doesn't yet have the ability to use them.
Implement support for in-memory remotes by configuring the remote via a
set of Git configuration environment variables. Until downstream callers
have been converted from on-disk to in-memory remotes, both ways will
stay supported. Afterwards, we can drop the `RefName` parameter, which
really is the remote name.
Changelog: added
|
|
When generating Go code from protobuf messages, we always have a
mismatch between declared variables and generated identifiers. This
leads to a mismatch in generated documentation, where the variable
documentation does not start with the Go variable name as it is best
practice in Go. Because of this, we have started to use Go identifiers
in protobuf documentation to fix the discrepancy.
Update documentation of variables in messages related to
UpdateRemoteMirror to do so consistenly.
|
|
The new "v14" version of the Gitaly module is named to match
the next GitLab release. The module versioning is needed in
order to pull gitaly as a dependency in other projects. The
change updates all imports to include v14 version. The go.mod
file was modified as well after go mod tidy execution. And
the changes in dependency licenses are reflected in the NOTICE
file.
Part of: https://gitlab.com/gitlab-org/gitaly/-/issues/3177
|
|
We're in the process of getting rid of on-disk remotes, instead of
asking the caller to always pass enough context, such that Gitaly is
able to construct an in-memory remote. FindRemoteRootRef is another of
these RPCs which currently only takes a remote name and thus relies on
on-disk state. This commit thus adds a new `RemoteUrl` parameter to the
RPC request such that callers can provide a URL instead of a name. To
enable authentication, we also add support for setting up HTTP headers.
|
|
The FindRemoteRootRef RPC doesn't have any documentation in the protobuf
sources. Add some.
|
|
While UpdateRemoteMirror performs a mutating action on a remote
repository which potentially is not under our control, it will never
modify the local target repository. It thus doesn't make a lot of sense
to treat it as a mutator: it's never mutating local state, and if it
targets a remote repository which is hosted by Gitaly, too, then it'd
use normal routing and thus have mutator semantics on that remote.
Relabel the RPC as an accessor to stop it from having transactional
semantics: we never create any transactions as nothing changes, which
causes us to always schedule replication jobs. And second, doing the
same push from all three nodes at once is definitely not going to work.
|
|
This commit adds documentation on UpdateRemoteMirror's protobuf
definitions.
|
|
Almost two years ago, we've grown a new `RemoteService/ListRemotes` RPC.
fd1fae703 (Merge branch 'list-git-remotes' into 'master', 2019-04-10).
The intent of this RPC is to list all remotes which are currently set up
in a given repository, where the use case is to avoid recreating remotes
in case they already do exist. That usecase has never materialized
though: Rails ensures that a remote exists by simply recreating it every
time it's needed. Thus, no users have surfaced since its introduction.
We're currently in the process of deprecating use of remotes altogether
in Gitaly: they require on-disk state which is hard to track. They
require Rails to maintain additional state in Gitaly without providing
much of a benefit. And ultimately, Rails always has all info about a
given remote at hand anyway at any point in time because otherwise it
wouldn't be able to recreate remotes. Instead, Rails will be migrated to
use anonymous remotes instead by only providing an URL, a refspec and
credentials. We then directly fetch via these parameters without
creating any remotes.
Let's thus drop the `ListRemotes` RPC: we do not want to encourage
anybody to start using it now that remotes are about to go away.
|
|
Scope of the FindRemoteRepository RPC call changed to STORAGE.
Storage value of the incoming message can be changed by new
'SetStorage' method.
Human-readable string for 'Scope' type with default string formatting.
Closes: https://gitlab.com/gitlab-org/gitaly/-/issues/2442
|
|
It is a first steps towards making FindRemoteRepository RPC
to become STORAGE scoped. It is needed to simplify routing
in Praefect and omit need for Praefect to handle this RPC
as a special case. After change is done the request will be
routed into one of the Gitalies and handled there. The Git
is not needed to be installed on Prafect node in order to
support the implementation of only single RPC.
Part of: https://gitlab.com/gitlab-org/gitaly/-/issues/2442
|
|
The `Gitlab::Git::Ref` initializer, which `Branch` inherits, already
removes the `refs/heads|tags/` prefix from the provided name via
`Gitlab::Git.ref_name`, so there should be no functional difference to
providing the "canonical name".
In a future commit, we'll store the canonical name in addition to the
non-prefixed name.
|
|
Extracting lint-related stuff into separate proto file. It
is required in order to have proper working proto-linter.
Previously it was using compiled files for verification and
it fails in some cases
(https://gitlab.com/gitlab-org/gitaly/-/jobs/459024976).
lint.proto extracted from shared.proto and contains
lint-related declarations. New task `proto-lint` added to
compile source code that is required by `protoc-gen-gitaly`.
`protoc-gen-gitaly` fixed to use proper proto source data.
Regeneration of all proto-related files.
|
|
This updates RemoteService and RemoteMirror to take a
`delete_divergent_refs` parameter which defaults to `true` (the current
behavior), and allows disabling the behavior on a per-mirror basis.
The option will be provided by the client and will be behind a feature
flag there.
|
|
Instead of setting OID in the RPC method use annotation in the field
(`target_repository` and `additional_repository`). Having only this 2
annotations created a problem with messages that can be either target
or additional repository (for example `ObjectPool`). Those are marked
with `repository` annotation and `target_repository` and
`additional_repository` are used in the parent messages.
Signed-off-by: Mateusz Nowotyński <maxmati4@gmail.com>
Signed-off-by: jramsay <maxmati4@gmail.com>
|
|
|
