The GitLab GraphQL Hack: Get Instant CI/CD Component Metrics
GitLab’s GraphQL API is a powerful tool for developers, offering a flexible and efficient way to interact with GitLab’s data. If you’re looking to automate tasks, retrieve specific information, or build custom integrations, GraphQL is your friend. In this post, I’ll walk you through how I used it to retrieve detailed component information and metrics from GitLab’s CI/CD catalog.
What is GraphQL?
Unlike traditional REST APIs, where you often get more data than you need, GraphQL allows you to specify precisely what data you want. This means fewer requests and more efficient data retrieval. Think of it as asking for exactly what you need from a menu, rather than getting the whole buffet.
My Use Case: Getting CI/CD Component Details
I needed to extract detailed information about CI/CD components within a specific GitLab group. Specifically, I wanted to get:
- Component names and IDs.
- The
includePath
for each component. - Input parameters (names, defaults, descriptions, types, and required status).
- Metrics related to usage.
This information was essential for gaining insights into component usage. Unfortunately, the same information is not available through the Gitlab REST API.
Using GitLab’s GraphQL Explorer
GitLab provides a handy GraphQL Explorer, which is a great place to test queries and explore the API. I started by crafting a query to retrieve the necessary data.
URL — https://gitlab.com/-/graphql-explorer
Here’s the query I used:
GraphQL
query getCiCatalogResourceComponents($fullPath: ID!) {
ciCatalogResource(fullPath: $fullPath) {
id
webPath
starCount # starCount
last30DayUsageCount # last30DayUsageCount
versions(first: 1) {
nodes {
id
components {
nodes {
id
name
includePath
inputs {
name
default
description
required
type
__typename
}
__typename
}
__typename
}
__typename
}
__typename
}
__typename
}
}
And here’s the variables JSON I passed.
JSON
{
"fullPath": "edgeworks-public/uipath-releaser"
}
Breaking Down the Query
ciCatalogResource(fullPath: $fullPath)
: Fetches the CI/CD catalog resource by its full path.starCount
andlast30DayUsageCount
: Provides invaluable metrics on component popularity and usage.versions(first: 1)
: Retrieves the latest version of the resource.components.nodes
: Delves into the component details, includingincludePath
andinputs
.inputs
: Extracts parameter specifications.
If you're trying to fetch using the conventional curl command, below is a code snippet
query=$(curl --request POST \
--header "Authorization: Bearer $TOKEN" \
--header "Content-Type: application/json" \
--url "https://gitlab.com/api/graphql" \
--data '{ "query": "query getCiCatalogResourceComponents($fullPath: ID!) { ciCatalogResource(fullPath: $fullPath) { id webPath starCount last30DayUsageCount versions(first: 1) { nodes { id components { nodes { id name includePath inputs { name default description required type __typename } __typename } __typename } __typename } __typename } __typename } }", "variables": { "fullPath": "edgeworks-public/uipath-releaser" } }')
Token
: Get a PAT token from your profile with api
or read_api
Tips for Using GitLab GraphQL
- Explore the Schema: Use the GraphQL Explorer to understand the available fields and types.
- Start Simple: Begin with basic queries and gradually add complexity.
- Use Variables: Variables make your queries more flexible and reusable.
- Authentication: Ensure you have the correct access token and permissions.
Conclusion
GitLab’s GraphQL API is a powerful tool that can significantly improve your workflow. By using it to retrieve detailed component information, I was able to gain valuable insights into my CI/CD pipelines. If you’re looking to streamline your GitLab interactions, I highly recommend giving GraphQL a try.
I hope this helps you get started with Gitlab’s GraphQL API, and that it helps you get the information you are looking for.