Two Days, 20 Commits — How I Started Contributing to GitLab Orbit

Context: I'm a GitLab Community Contributor. This records my first Orbit contributions through the community fork in June 2026. The two days, 20 commits, 28 crates, and MR reviews remain the record from then. The October 8, 2026 operating update is under “If You Want to Contribute”; it does not replace those historical counts with today's project size.

What Is Orbit

My one-sentence understanding then: GitLab Orbit turns your code and development lifecycle data into a queryable graph.

More specifically. Your repo has code. GitLab has MRs, issues, pipelines, deployments. These things live in different places, and answering cross-cutting questions like "who calls this function," "what pipelines break if I change this file," or "how's the test coverage for this module" means stitching together multiple APIs yourself.

Orbit indexes everything into a property graph (code definitions, call relationships, inheritance chains, import graphs, plus MR / issue / pipeline SDLC data), then lets you query it with SQL or a Query DSL.

Two modes:

Orbit Local: Standalone CLI, indexes a single repo into a local DuckDB. No GitLab account needed. Takes a few seconds.
Orbit Remote: Hosted service, indexes an entire GitLab group into ClickHouse, with authorization and API endpoints.

Tech stack is Rust. A single workspace with 28 crates, supporting 11+ programming languages (Ruby, Java, Python, TypeScript, Rust, Go, C#, C/C++, Kotlin, Elixir, Bash). Code parsing via tree-sitter, OXC for JavaScript/TypeScript.

Sounds massive. It is. But that doesn't mean you can't contribute.

Finding an Entry Point

I started contributing to Orbit because of a hackathon. The GitLab Transcend Hackathon had a track built around Orbit. My team built a tool that uses Orbit graph queries to make AI code review auditable. While building it, I kept digging through Orbit's source code and docs, and kept finding things that could be improved.

The first entry point usually isn't code. It's documentation.

When I set up Orbit Local, the quickstart docs assumed you already had GDK (GitLab Development Kit) installed. But running Orbit Local doesn't need GDK at all. A lot of potential contributors probably give up at that step. So I wrote a quickstart guide that doesn't require GDK.

That was my first MR.

My Four MRs

In two days I submitted 4 MRs, each a different type:

1. docs/690: Orbit Local Developer Quickstart

The simplest one: a from-scratch quickstart that doesn't assume GDK. Covers protoc installation (Linux / macOS / Windows), build commands, running tests, common issues.

During review, the maintainer asked me to add Windows protoc paths and a note about ontology E2E test caveats. That's the real benefit of submitting MRs: the review process itself is where you learn.

2. feat/847: Java Sealed Type Permits Clause Extraction

This was Rust feature development. Java 17 introduced sealed classes (JEP 409), allowing a permits keyword to restrict which subclasses can extend a type. But Orbit's Java indexer never read this field, so sealed-type hierarchies were broken in the graph.

What I did:

Found the permits field in tree-sitter-java's AST, wrote a java_permitted_types() extractor
Added a new EdgeKind::Permits to the code graph
Registered the new edge kind in the ontology schema
Reused existing name resolution logic from link_extends (extracted into resolve_disambiguated_targets)
Added test fixtures

13 files changed, +237/-36 lines. Sounds like a lot, but most of it was following existing patterns. Orbit's code graph pipeline is well-designed, and adding a new edge kind has a clear path to follow.

3. fix/741: Indexer Log Fix for Skipped Long-Line Files

Classic "found this while using it" bug. When Orbit indexes a repo and hits a file with lines exceeding the limit, it skips the file silently, logging only at DEBUG level. At INFO level, you'd finish indexing with no idea files were skipped.

Simple fix: log a line at INFO when files are skipped, keep details at DEBUG. The maintainer's review simplified it further: drop the aggregate, just log each skip at DEBUG. A cleaner approach.

4. docs/850: Prerequisites as an On-Demand Reference

Orbit's prerequisites were scattered across several docs. I consolidated them into a standalone reference page, so you look it up when you need it instead of cluttering the quickstart.

Other Small Contributions

Beyond the four main MRs:

Documented Gemini CLI authentication for the Orbit MCP endpoint (turns out you need to explicitly request the mcp_orbit OAuth scope)
Added Kotlin suspend function test fixtures
Updated CLI docs for v0.74.0
Created a production runbook skeleton
Fixed a troubleshooting page redirect

Total: 20 commits, +1,260/-235 lines.

A 2,800+ Commit Rust Project Is Less Intimidating Than It Sounds

A few things that lowered the barrier:

Orbit's code graph pipeline is modular. Adding a new edge kind means following the pattern of EXTENDS or CALLS: add an extractor, add an edge kind enum variant, add ontology config, add fixtures. Every step has existing examples to follow. For the Java permits feature, roughly 80% of my time went to understanding "what's the current pattern," and only 20% to writing new code.

Orbit Local needs no infrastructure. No ClickHouse, no NATS, no GDK. Just cargo build and go. Local indexing takes seconds, so the edit → test loop is fast.

Documentation is real contribution. Don't think "it's just docs" means it doesn't count. My quickstart MR got just as thorough a review as the Rust code MR. For a fast-growing project, docs that lower the barrier for newcomers are genuinely valuable.

Maintainer reviews are constructive. I learned something from every MR. The feat/847 review had me flip the permits edge direction to align inversely with EXTENDS (better graph semantics). The fix/741 review taught me log-level design trade-offs. That kind of review quality is something you don't get from solo side projects.

If You Want to Contribute

A few suggestions:

Run Orbit Local first. The original glab orbit local index . and glab orbit local sql were the command shape I used in June. Use the version and commands below to index your own repo and try a few queries now. What you run into may be your first MR.
Check the issue tracker. Orbit has good first issue labels, usually docs, small fixes, or adding test fixtures for new languages.
Docs always need help. Especially installation steps, platform differences, common error handling. The pit you fell into is someone else's MR.
Submit through the community fork. GitLab community contributors use the community fork to submit MRs. Same workflow as any GitLab MR.
Don't be afraid of Rust. If you have experience in other languages, Orbit's Rust code is more approachable than you'd expect. The code graph layer is mostly tree-sitter AST operations and pattern matching. No deep lifetime gymnastics or async wizardry required.

October 8, 2026 update: installation and local queries

The current glab guide uses a flat command tree: glab orbit index and glab orbit sql, with glab 1.117 or later. These steps follow that documentation; this refresh did not reinstall a binary or rerun indexing.

# Check glab >= 1.117, then install its managed Orbit binary
glab version
glab orbit --install
glab orbit version

# Enter your repo, index the working tree, and query the local graph
cd /path/to/your/repo
glab orbit index .
glab orbit schema
glab orbit sql 'SELECT count(*) FROM gl_definition'

Once the binary is installed, local commands such as index and sql need no GitLab account or network and consume no GitLab Credits. They index the current working tree. Reindex after switching branches; a stored graph does not update itself. The default DuckDB is ~/.gitlab/orbit/graph.duckdb. SQL launched inside an indexed repo is scoped to that checkout; outside one, it covers every indexed commit. The working-tree and indexing guide explains that behavior.

October 8, 2026 update: Local and Remote agent access

To expose the local graph to an agent, the Local MCP guide uses glab orbit mcp serve. It is a stdio server, not a remote URL. Its tools are index, get_graph_schema, and read-only run_sql. Local MCP is still marked experiment; Local itself is beta. Neither status promises a stable generally available interface.

glab orbit setup assists agent integration, but writes agent instruction files and installs the Orbit skill. Check glab orbit setup --help and choose the agent and project/user scope before running it. You do not need that configuration change just to try SQL.

Remote queries require GitLab authentication and network access. glab orbit query uses the hosted graph's Query DSL and consumes Credits. A code relationship returned by local SQL does not mean you have indexed the GitLab group's issues, MRs, or pipelines. The June contribution story stays intact; for operating the tool now, use these entry points and check the installed version.

Wrapping Up

Two days, 20 commits, 4 MRs. Looking back, the barrier was genuinely lower than I expected.

Orbit is a fascinating project. Unifying code analysis and SDLC data into a queryable graph is a direction that will only become more important as AI-assisted development grows. And it's actively expanding (more languages, more query capabilities), so now is a good time to jump in.

If you're interested in code analysis, knowledge graphs, or Rust, GitLab Orbit is a great contribution target. Hope to see you in the community.