When FindCommit ref caching is enabled, negative matches would
previously not be cached. However, if a source branch is deleted,
there's no need to keep looking up the same commit. This change caches
the result of a nil commit.
Updates the gitaly client to use path_bytes field instead of the
deprecated path field in list_last_commits_for_tree_response.
Also adds a test to guard against non-utf8 path data
For a given merge request, it's quite common to see duplicate FindCommit
Gitaly requests because the Gitaly CommitService caches the request by
the commit SHA, not by the ref name. However, most of the duplicate
requests use the ref name, so the cache is never actually used in
practice. This leads to unnecessary requests that slow performance.
This commit allows certain callers to bypass the ref name to
OID conversion in the cache. We don't do this by default because it's
possible the tip of the branch changes during the commit, which
would cause the caller to get stale data.
This commit also forces the Ci::Pipeline to use the full ref name
so that caching can work for merge requests.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/57083
Implements list_last_commits_for_tree to communicate with the
ListLastCommitsForTree Gitaly RPC
Bumps the Gitaly server version
Bumps the Gitaly-Proto gem version
Even if it doesn’t save lines of code, since people will tend to use
code they’ve seen. And `SafeRequestStore` is safer since you
don’t have to remember to check `RequestStore.active?`.
We used to apply this limitation on GitLab when using Rugged. Now that
we've shifted to Gitaly, this parameter needs to be sent via a RPC
request. Currently this value is hardcoded on Gitaly.
When we save merge request diffs to the database, we need to expand the diff
before doing so. That's so that we can expand diffs (within the normal limits)
without hitting the repository, but just by going to the database.
This is done implicitly - diffs are expanded unless we say otherwise. However,
we have another option we can pass, that lets us enforce diff size limits, that
defaults to true.
Prior to this commit:
- The Rugged code path defaulted to setting `expanded: true` and
`enforce_limits: true`.
- The Gitaly code path defaulted to setting `expanded: false` and
`enforce_limits: true`.
This was introduced by eb36fa17a6, which
implemented the initial feature. Since then, if the `gitaly_diff_between`
feature flag was enabled, MRs would have diffs that could not be expanded in
some cases, with no fix other than to disable the feature flag and force push to
the MR to refresh the diff in the database.
Batching commits for performance improvements, might lead to empty
batches being used. This isn't the case yet, but to guard against this
in future cases, a guard clause is added.