[go: up one dir, main page]

Skip to content

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.