GitLab Orbit indexed data

  • Tier: Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

GitLab Orbit indexes two kinds of data into one graph:

  • Software development lifecycle (SDLC) objects from GitLab, such as groups, projects, users, merge requests, pipelines, work items, and security findings
  • Source code on the default branch of each project, such as files, directories, definitions, imports, and calls

Binary files get only a File node, with no definitions. GitLab Orbit does not index other branches. The local graph on your machine holds only code.

The graph links these objects. For example, a merge request belongs to a project, runs a pipeline, and fixes a vulnerability. A file is on a branch of the project and defines a definition.

Project hub graph. A merge request, a pipeline, a vulnerability, and a branch link to the project. A file on the branch defines a definition.

Project hub graph. A merge request, a pipeline, a vulnerability, and a branch link to the project. A file on the branch defines a definition.

Get the live schema

The node types, properties, and relationships change between releases. To see the current schema, use one of these methods:

  • In GitLab, in the top bar, select Search or go to > Your work > GitLab Orbit, then select the Schema tab. On GitLab.com, go to https://gitlab.com/dashboard/orbit/schema. For more information, see GitLab Orbit dashboard.
  • In a terminal, run glab orbit schema. To show the properties and relationships of node types, add their names, for example glab orbit schema MergeRequest Project.
  • In GitLab 19.6 and later, in the GraphQL API, query Query.orbit.schema. For more information, see OrbitSchema.
  • In a query, for example in the Query editor tab of the GitLab Orbit dashboard or with glab orbit query, run CALL db.schema().

Supported languages

Each language gets files, directories, and definitions. Most languages also get imports and cross-file calls.

LanguageFile extensions
Bash/Shell.sh, .bash, .zsh
C.c, .h
C++.cpp, .cc, .cxx, .hpp, .hh, .hxx
C#.cs
Elixir.ex, .exs
Go.go
HCL (Terraform).tf, .tfvars
Java.java
JavaScript.js, .jsx, .mjs, .cjs, .vue, .graphql, .gql, .json
Kotlin.kt, .kts
Lua.lua
PHP.php, .phtml, .php3, .php4, .php5, .php7, .phps
Python.py
Ruby.rb, .rbw, .rake, .gemspec
Rust.rs
Scala.scala, .sc
Swift.swift
TypeScript.ts, .tsx, .mts, .cts
YAML.yml, .yaml
Zig.zig

Some languages have limits:

  • Bash/Shell: function definitions and source or . imports only. No cross-file calls.
  • Rust: cross-file CALLS and EXTENDS relationships. No other reference relationships.
  • YAML: anchors and aliases. Mapping keys become definitions only in GitLab CI, ArgoCD, Helm, and Docker Compose files. No cross-file references.

Files in other languages still get a File node, with no definitions.

Properties resolved at query time

The graph does not store some properties. The server fetches them from the repository when your query asks for them.

Node typePropertyValue
FilecontentFull source text of the file
DefinitioncontentSource text of the definition
MergeRequestdiffFull unified diff of the merge request
MergeRequestDiffpatchFull unified patch of the diff version
MergeRequestDiffFilediffPatch of one changed file. null when too_large is true.

Use these properties to read code without a separate call to the GitLab API.

Identifiers

  • Query responses return all entity IDs as strings, even when the stored value is an integer. String IDs prevent precision loss in JavaScript clients for values above Number.MAX_SAFE_INTEGER.
  • On the server, a Definition ID is a hash of the project, branch, file path, fully qualified name, and position of the definition. The same function in two projects has two different IDs.