What Is Cross-Repo
Dependency Mapping?
Cross-repo dependency mapping automatically discovers and tracks how repositories in a software organisation depend on each other — answering the question "if I change repo A, what else breaks?" before you make the change.
Cross-repo dependency mapping is the practice of automatically discovering and tracking how repositories in a software organisation depend on each other, by parsing actual source files and building a directed graph of consumer-to-producer relationships across all repos in a GitLab group or GitHub organisation.
Unlike service catalogs (which require manual declaration) or dependency update tools (which react after a new version is published), cross-repo dependency mapping is auto-discovered from code and answers questions before a change is made.
Tribal knowledge is not a dependency strategy
Modern platform and infrastructure teams maintain shared components consumed across many repositories. A Terraform module might be sourced by forty repos. A Docker base image might be pulled by every service in the org. A GitLab CI template might be included by eighty pipelines.
When any of these shared components change, the teams consuming them need to know. Without cross-repo dependency mapping, this knowledge exists only as tribal knowledge in senior engineers' heads. When those engineers leave, go on holiday, or simply can't keep up with the growing number of repos, the organisation loses visibility into its own dependency graph.
The consequences are predictable: breaking changes cascade silently, incident response slows because nobody can trace what depends on what, and new engineers have no way to understand the infrastructure's interconnections.
Silent cascades
Breaking changes propagate through the graph without warning, surfacing only in production failures.
Slow incident response
Engineers spend hours manually grepping repos to trace what depends on a failing component.
Stale catalogs
Service catalog entries go out of date the moment they are created; no tool enforces correctness.
From raw repos to a queryable dependency graph
- 01
Enumerate
Every repository in a GitLab group or GitHub organisation is listed via the platform API — no manual inventory needed.
- 02
Clone
Each repo is shallowly cloned at the default branch. Only the source tree is needed; full history is skipped for speed.
- 03
Parse
Source files that declare dependencies are parsed: Terraform source blocks, Dockerfile FROM statements, CI include directives, Helm Chart.yaml, go.mod, package.json, requirements.txt, and more.
- 04
Detect artifacts
Each repo is also inspected for what it produces: a Docker image, a Python package, a Helm chart, a Terraform module.
- 05
Resolve
Parsed references are resolved to the actual repos or artifacts within the organisation, connecting consumers to producers.
- 06
Build the graph
A queryable directed graph of consumer-to-producer relationships is assembled across the entire org, ready for impact analysis.
The key distinction from other approaches is that the graph is built from what is actually in the code, not from manually maintained metadata. This means it stays current as repos change, without requiring engineers to update a catalog or manifest.
What ecosystems it covers
Cross-repo dependencies exist across every infrastructure and application ecosystem. A comprehensive dependency mapping solution covers all of them — and tracks them together.
- Terraform modules
- Docker base images
- GitLab CI templates
- GitHub Actions workflows
- Helm chart dependencies
- Ansible roles & collections
- Python packages
- Go modules
- npm packages
- Kubernetes & Kustomize
The real value emerges when these ecosystems are tracked together. A Terraform module change might affect a Docker build, which affects a CI pipeline, which affects a Helm deployment. Single-ecosystem tools miss exactly these cross-boundary connections.
Most valuable for teams managing shared infrastructure
-
Platform engineers
Build and maintain shared infrastructure components consumed by dozens of other teams.
-
DevOps & SRE teams
Need instant blast-radius analysis during incident response to trace what depends on what.
-
Engineering managers
Coordinating breaking changes across teams without days of manual dependency discovery.
-
Organisations with 50+ repos
Using a polyrepo setup — especially those with multiple infrastructure ecosystems.
The problem typically becomes acute when an organisation passes roughly 50 repositories, and becomes critical past 100. It is most painful for teams using multiple ecosystems (Terraform, Docker, CI templates, Helm) rather than a single tool.
Riftmap: a cross-repo dependency mapping tool
Riftmap is a change impact engine for multi-repo systems. It scans a GitLab or GitHub organisation with a single read-only access token, automatically discovers every cross-repo dependency from the actual source files across all 10 ecosystems, and builds an interactive dependency graph with visual blast-radius analysis. No per-repo configuration. No YAML to maintain.
Common questions
01 What is cross-repo dependency mapping?
Cross-repo dependency mapping is the practice of automatically discovering and tracking how repositories in a software organisation depend on each other. It answers the question: if I change something in repo A, which other repos are affected? The graph is built by parsing actual source files — not from manually maintained metadata.
02 How is cross-repo dependency mapping different from a service catalog?
Service catalogs (like Backstage) require teams to manually declare their dependencies and keep entries up to date. Cross-repo dependency mapping is auto-discovered directly from code, so it stays current without any human maintenance. It also answers impact questions before a change is made, whereas service catalogs are primarily reference directories.
03 How does cross-repo dependency mapping work?
A dependency mapper enumerates every repository in a Git organisation, shallowly clones each one, and parses source files that declare dependencies — Terraform source blocks, Dockerfile FROM statements, CI include directives, Helm Chart.yaml, go.mod, package.json, and more. It then resolves those references to actual repos and builds a directed graph of consumer-to-producer relationships.
04 What ecosystems does cross-repo dependency mapping cover?
A comprehensive solution covers Terraform modules, Docker base images, GitLab CI and GitHub Actions templates, Helm chart dependencies, Ansible roles and collections, Python packages (requirements.txt, pyproject.toml), Go modules (go.mod), npm packages (package.json), and Kubernetes/Kustomize resource references. The real value comes from tracking all ecosystems together, since a change can cross ecosystem boundaries.
05 Which teams benefit most from cross-repo dependency mapping?
Platform engineering teams that maintain shared infrastructure components, DevOps and SRE teams that need blast-radius analysis during incidents, and engineering managers coordinating breaking changes across teams. The problem typically becomes acute at 50+ repositories and critical past 100, especially in organisations that use multiple infrastructure tools.