Gitaly itself hold very little state, other than the data on disk. This
limits the interfaces to set feature flags. Gitaly now has the ability
to interpret the request metadata to check for feature flags.
https://gitlab.com/gitlab-org/gitaly/merge_requests/704
This allows clients control on the Gitaly server, and given that Rails
has an internal chatops interface to set these values this was chosen as
solution.
Known limitation right now, is that this package doesn't support the opt
out that other Gitaly features do.
Prior to this change, this was done through unicorn. In theory this
could time out. Workhorse has been sending these raw patches and diffs
for a long time and is stable in doing so.
Added bonus is the fact that `Commit#to_patch` can be removed.
`Commit#to_diff` too, which closes
https://gitlab.com/gitlab-org/gitaly/issues/324
Closes https://gitlab.com/gitlab-org/gitaly/issues/1196
The refs hash is used to determine what branches and tags have a commit
as head in the network graph. The previous implementation depended on
Rugged#references. The problem with this implementation was that it
depended on rugged, but also that it iterated over all references and
thus loading more data than needed if for example the project uses CI/CD
environments, Pipelines, or Merge Requests.
Given only refs are checked the network cares about the GraphHelper#refs
method has no need to reject those, simplifying the method.
Closesgitlab-org/gitaly#880
Uses `list_commits_by_oid` on the CommitService, to request the needed
commits for pipelines. These commits are needed to display the user that
created the commit and the commit title.
This includes fixes for tests failing that depended on the commit
being `nil`. However, now these are batch loaded, this doesn't happen
anymore and the commits are an instance of BatchLoader.
Now, when requesting a commit from the Repository model, the results are
not cached. This means we're fetching the same commit by oid multiple times
during the same request. To prevent us from doing this, we now cache
results. Caching is done only based on object id (aka SHA).
Given we cache on the Repository model, results are scoped to the
associated project, eventhough the change of two repositories having the
same oids for different commits is small.
the rugged versions up to 0.26.0b3 had a bug concerning the signature
extraction. The extracted signature was not always the same, probably
due to a buffer (overflow) issue in libgit.
see https://github.com/libgit2/rugged/issues/608
This solves a problem where commits populated with Gitaly were not equal
to commits populated with Rugged. This is because Gitaly may not return
all fields of a commit for optimizations purposes, which resulted in
false negatives when comparing the same commit (commits with the same
sha) with different sources.
Zeger-Jan van de Weg
Jacob Vosmaer
Ahmad Sherif
Sean McGivern
Micaël Bergeron
micael.bergeron
Kim "BKC" Carlbäcker
Alejandro Rodríguez
Douwe Maan
Brian Neel
Alexis Reigel
Kevin O'Connor
Bob Van Landuyt
Robert Speicher