Full GraphQL API support for path locks
Proposal
In !61380 (merged) we expose path locks in the graphql API. Currently, there is no REST API support for them - only a Rails controller that is oriented to operating on individual path locks. This results in N+1 issues when trying to work on several paths at a time in the current frontend.
The repository view is being refactored to use graphql, so we don't really need the REST API, but the implementation going in doesn't allow us to filter path locks by path. They're not a well-used feature, but in cases where a repository has a great many path locks, this leads to inefficiencies and unnecessary frontend work.
We should add the following arguments to the graphql API for path locks:
paths
exact_match
downstream
The first is an array of strings, which filter the path locks we'll return by path. The latter two are booleans that alter the meaning of the paths - if exact_match
is false
, then we'll return a path lock of, say, app/
when the path is app/models/project.rb
. If downstream
is true, we'll return a path lock of, say, app/models/project.rb
when the path is app/
.
Currently, path locks are filtered by Gitlab::PathLocksFinder
, which is oriented to finding a single path lock at a time, so it's not suited for the new GraphQL API. As part of this, we'll need to make this into a "proper" finder and refactor the existing users to cope.