Skip to main content

v2.14.0

Release notes for orun v2.14.0.

This release lands the catalog-state work: a single content-addressed catalog that powers change detection, a new orun catalog command group, and a live, change-aware cockpit.

Highlights​

  • One change-detection engine. orun plan/run --changed, the new orun catalog affected, and the cockpit now all compute changed/affected components from the same engine over the object-model catalog — classified against the catalog's ownership map and dependency graph, with an over-report (never under-report) guarantee on ambiguity. The legacy file-walking selector has been retired.
  • orun catalog command group. Resolve, persist, and inspect the component catalog directly — including orun catalog affected to see exactly which components a change touches (directly-changed, dependents, blast radius, and the plan/run selection) with a confidence signal.
  • Live, change-aware cockpit. The component list refreshes without a keystroke, badges directly-changed vs affected components (with a show-only-changed filter), drills down catalog → component → job → logs, and can launch a component-scoped run in a selected environment.

The catalog​

orun maintains a content-addressed object-model catalog under .orun/objectmodel/ — the resolved component set, its dependency graphs, and an impact/ index (ownership map + per-component fingerprints), with catalogs/current pointing at the latest snapshot. It is the read model for change detection and the cockpit.

The catalog stays fresh on its own: orun plan and a universal pre-run refresh hook keep catalogs/current current transparently (a clean re-resolve is a cheap ref move, not a rewrite). You can also manage it explicitly:

orun catalog refresh          # resolve + persist a snapshot (and the impact index)
orun catalog list             # components in the current catalog
orun catalog tree             # the relationship graphs
orun catalog diff <a> <b>     # compare two snapshots

Inspecting change detection​

orun catalog affected exposes the engine that --changed uses:

orun catalog affected --base main --head HEAD
orun catalog affected --files apps/api/main.go --json
FieldMeaning
directlyChangedcomponents whose own inputs changed
dependentscomponents that transitively depend on a changed one
affectedthe cockpit blast radius (directlyChanged + dependents)
selectionthe plan/run job set (directlyChanged + include:always deps)

The --json envelope adds confidence, needsFullResolve, intentMode, and catalogId — the provenance to explain a selection in CI. A component.yaml edit is treated as structural (lower confidence, needsFullResolve).

--intent-impact (watch/all/none) controls how a global intent.yaml change scopes components, honoring per-component spec.change.watches — unchanged from prior behavior, now implemented by the shared engine.

Cockpit: the component catalog view​

The cockpit's Browse surface now reads the catalog and stays live:

  • Keystroke-free refresh — edits on disk, or a catalog written by an external orun plan/run, appear within a few seconds. ctrl+r still forces a refresh.
  • Changed / affected overlay — a filled dot marks a directly-changed component, a hollow dot one affected via a dependency; c filters to just those rows.
  • Drill-down — ⏎ opens a Component page (resolved detail + the runs that touched it); drill into an execution for run → job → logs.
  • Environment selector + run — cycle the selected environment with e; from a component page, r launches a component-scoped run for that environment (when the component is active in it) through the same path as orun run.

--explain note​

--explain on plan/run reports ref resolution (which base/head were used). The per-component classification — including intent-watch matching — now lives in orun catalog affected (use --json for the full provenance), rather than being printed inline by --changed --explain.

Compatibility​

  • The object-model catalog is additive; it is written transparently and absorbed by content-addressing (the first resolve after upgrading re-derives the catalog id once, then stabilizes). No migration is required, and older catalogs remain readable.
  • --changed flags, CI auto-detection, trigger-driven scoping, and --intent-impact behavior are unchanged.
  • On-disk run state and log layout are unchanged.

References​