MVC - Backend: Create fields to make query which returns a list of projects where components were used in a pipeline - GraphQL
Why are we building this feature?
Central DevOps teams in large organizations need to know which projects are using components and what those components are. This will help them:
- Run a security audit on components used in their organization
- Update components that are using an outdated or vulnerable version
This issue is the first iteration of solving this problem. It proposes that we add a GraphQL query that returns the data needed.
There are two different users who will run this query, depending on whether the GitLab instance is self-managed or not:
- On gitlab.com: maintainers of groups should be able to run this query only for groups they maintain.
- On self-managed: only instance admins should be able to run this query.
This will be a paid feature for Premium customers only.
Implementation details:
BIG NOTE! This feature is for Premium customers ONLY so it must be in EE!
Let's add the following query to our GraphQL:
For a given group
query {
group(fullPath: "<group_path>") {
id
name
projects {
nodes {
fullPath
componentUsages {
nodes {
name
version
lastUsedDate
}
}
}
}
}
}
For a given project
query {
project(fullPath: "<project_path>") {
id
componentUsages {
nodes {
name
version
lastUsedDate
}
}
}
}
For all projects user has access to
query {
projects {
nodes {
componentUsages {
nodes {
name
version
lastUsedDate
}
}
}
}
}
Important notes
- When
groupId
is given, the data returned should include projects using components for the requested group and all sub-groups. - The
groupId
argument is required for gitlab.com customers. It is not required for self-managed. - If
groupId
is not given for self-managed customers, the returned data should include all projects using components - Depending on how the data is structured in the database (I - @avielle - am not sure), this endpoint might be performance intensive
- For now, mark all new fields as
alpha
and make an issue for us to removealpha
in a year. We might want to restructure the query in the future. For example, we might want to return a tree of groups with their projects nested inside. (For now I think it's okay to return all the projects in one list)
Edited by Rajendra Kadam