By specifying `key`, we get a different lazy batch loader for each
repository, which means that accessing a lazy object from one repository
will only result in that repository's objects being fetched, not those
of other repositories, saving us some unnecessary Gitaly lookups.
Having this in a concern allows us to reuse it for different single
purpose classes that call out to git without going through the
repository every time.
Cleanup code, and refactor tests that still use Rugged. After this, there should
be no Rugged code that access the instance's repositories on non-test
environments. There is still some rugged code for other tasks like the
repository import task, but since it doesn't access any repository storage path
it can stay.
Prior to this change, most the commits counted were done through Gitaly.
This removes the last point where this wasn't the case.
This makes the `rugged_count_commits` method obsolete, with its tests.
Closes https://gitlab.com/gitlab-org/gitaly/issues/315
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