Skip to content

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:

  1. Run a security audit on components used in their organization
  2. 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:

  1. On gitlab.com: maintainers of groups should be able to run this query only for groups they maintain.
  2. 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 remove alpha 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