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.