Guides

Diff View

Compare live cluster state with the rendered source before syncing — planned

Diff View — ❌ not implemented

This feature doesn't exist yet. There is no diff engine in the server or operator — GET /api/v1/apps/{ns}/{name}/diff returns 404, and the CLI has no wardn app diff command. The sections below describe the intended design, kept for reference.

What exists today

Closest available signals for "what will a sync change?":

  • GET /apps/{ns}/{name}/status — sync_status + health + health_reason tell you whether live and rendered state differ, and why
  • POST /apps/preview — for image sources, resolves the digest a given spec would deploy (incl. ?app=name to echo the current spec for a client-side diff)
  • status.operationState — the outcome of the last sync op (Succeeded/Failed/Held) plus the revision it applied
  • kubectl diff -f — run against your rendered manifests locally; Wardn doesn't host this

Intended design (unbuilt)

When the diff engine lands, the target is:

  • Compute per-resource diffs between live and rendered manifests — only fields managed by Wardn's field manager, not status or API-server defaulting
  • Surface the diff inline on the app page when sync_status is OutOfSync
  • A wardn app diff CLI command and GET /apps/{ns}/{name}/diff API endpoint
  • ignoreDifferences (JSON pointers) to exclude HPA/controller-managed fields

Common scenarios the diff should cover

ScenarioLiveDesiredDiff shows
Image tag changev1.2.3v1.2.4one-line tag diff
Replica drift (manual kubectl scale)35scale diff — relevant once selfHeal is wired
New resource in Gitabsentpresent+++ additions
Resource removed from Gitpresentabsent--- removal (pruned when prune: true)

Rollback

Roll back applications to previous applied revisions

Sync Waves and Hooks

Order resource application with sync waves and lifecycle hooks

On this page

Diff View — ❌ not implementedWhat exists todayIntended design (unbuilt)Common scenarios the diff should coverRelated