| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Enforce that services must have a comment and add a placeholder for all
instances where such a comment is missing.
|
|
|
|
Issue: https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1219
Changelog: added
|
|
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
|
|
The `smarthttp.InfoRefsReceivePack` RPC is currently labelled as
mutator. Taking a closer look at it, there is no way it can change any
objects in the repo though, as it will always either spawn `git
receive-pack --stateless-rpc --advertise-refs` or `git upload-pack
--stateless-rpc --advertise-refs`. While git-receive-pack(1) may modify
the repo, it won't ever do so with the `--advertise-refs` flag, as it
will cause the command to only advertise references and then exit
immediately afterwards.
As the RPC is called in quick succession with `smarthttp.PostUploadPack`
in case a user performs a push, the first call to InfoRefsReceivePack
would've increased the repository generation and caused replication jobs
to be created. As a result, when PostUploadPack gets invoked it is
likely that secondaries will be treated as out-of-date as replication
jobs usually weren't processed yet. This in turn breaks transactions, as
we will now only add the primary to any transaction for all pushes via
smarthttp.
So let's relabel the RPC as an accessor to avoid replication when it's
called and fix the described issue.
|
|
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.
|
|
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>
|
|
|
|
|
