Inspect existing OCI packages

A repository document, rendered for the site. View source markdown.

Generated at: 2026-07-30T12:38:02.000Z UTC · source: committed helm-expt evidence for this rendered repository document.

Use one command to identify a supported OCI package, resolve its immutable digest, and report what is actually inside it:

npm run oci:inspect -- OCI_REFERENCE

The command distinguishes source packages from literal Kubernetes configuration. For a literal bundle it pulls the layers, parses the Kubernetes objects, counts CRDs, hooks, Jobs, and Secrets, checks duplicate identities, and flags common unfinished values. For a cub installer source package, add --render to select a preset config and inspect the objects without applying them.

Checked examples

ExamplePackage kindObjectsResultReport
AICR literal Kubernetes configurationliteral Kubernetes configuration17passJSON
Kubara literal Kubernetes configurationliteral Kubernetes configuration77passJSON
AICR Helm source packageHelm chart source package0passJSON
Public cub installer package rendered with its default configcub installer source package6passJSON

The AICR and Kubara examples are committed local OCI image layouts and are re-read by npm run oci:inspect:verify. The NGINX report was produced from the public package at its immutable digest; the network-free verifier checks it against the publication receipt, package definition, and checked render. Use npm run oci:inspect:verify-live to pull and render that public package again.

Keep the package roles separate

Package roleWhat the report can inspect
Helm chart sourceChart metadata and layers. Render it before expecting Kubernetes objects.
cub installer source packagePreset configs, package files, and requirements; use --render for the selected objects.
Literal Kubernetes configurationExact objects, object kinds, obvious lifecycle work, companion records, and basic checks.
Unknown OCI packageManifest and layer metadata, plus any readable YAML or JSON objects found.

This report is deliberately narrower than a deployment proof. It does not claim that Kubernetes admitted the objects, a controller reconciled them, or the workload became healthy.