Using Graph Status in CI

When a team commits its code map, the map can fall out of sync if someone forgets to rebuild it. Running vg status in CI catches this automatically. This guide shows how to use graph freshness as a pipeline check so your shared map stays trustworthy.

Overview

vg status compares the committed graph against the current working tree and reports staleness along with node and edge counts and resolver rungs. In CI, that comparison becomes a quality gate: if the committed map does not match the code, the pipeline can surface it before the change merges.

Prerequisites

Your repository should already share the code map so it is committed. If not, enable that first:

vg share

Step 1 — Build and check in the pipeline

In your CI job, ensure the map is built and then check its status against the checked-out tree:

vg build
vg status

Building first guarantees the artifact exists; vg status then reports whether it is current.

Step 2 — Interpret the result

Use the status output to decide whether the map is fresh. A stale graph means the committed artifact lags the code in the branch — a signal that the author should rebuild and recommit. Treat freshness as part of your definition of done for the shared map.

Step 3 — Keep contributors honest

Because vg share installs a pre-commit hook, most staleness is prevented at commit time. The CI check is a backstop for cases where the hook was bypassed or skipped. Together they keep the shared map reliable without manual policing.

Combining with scans

Graph freshness pairs well with your existing drift gates. A typical pipeline runs a scan for drift and also confirms the code map is current:

vg scan --fail-on error
vg status

This gives reviewers both an up-to-date DriftScore and an up-to-date structural map.

Related

• Check freshness with vg status.
• Make the map committable with vg share.
• Build or update the map with vg build.

All checks run locally in your CI runner; nothing is uploaded by vg status.