velero/velero

1. Get the exact objects Run for this entry

The Catalog rendered this entry and retains its 23 objects in one file.

An upload can create more Units than the objects counted here. The installer renders a Namespace, and the upload adds an installer-record Unit.

# fetch the retained objects for this entry
$ curl -fsSL -o velero-velero-12-1-0-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/velero/velero/12.1.0/revisions/default/r001/rendered/release-objects.yaml

# check the bytes against the listing
$ shasum -a 256 velero-velero-12-1-0-default.yaml
98ae56afed33da670906bb8ea003f7abd1ec19e4bbc42244590bc2e97f772d3f  velero-velero-12-1-0-default.yaml

# render this base from the signed package; step 3 uploads this directory
$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/velero-velero:12.1.0@sha256:4f79e7fbd3e4a3564746dcfdc45091f43cb8faeb1a569e5cd6825576fcdd3882 --base default --work-dir ./velero-velero-12-1-0-default --non-interactive --namespace velero

2. Compare with another version or base Not run for this entry

The listing records no comparison for this entry. The commands run on the retained files, with no account. The Catalog holds one other version, 12.0.1.

# fetch the default base at version 12.0.1
$ curl -fsSL -o velero-velero-12-0-1-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/velero/velero/12.0.1/revisions/default/r001/rendered/release-objects.yaml

# list what changed from 12.0.1 to 12.1.0
$ cub config diff velero-velero-12-0-1-default.yaml velero-velero-12-1-0-default.yaml --summary

3. Upload it as a variant Not run for this entry

The Catalog has not uploaded this entry. The commands use its signed installer package. Read the log of the live walk on 2026-10-08.

Replace each value in angle brackets with a name of your own. The entry id may already exist as a Space in your organization, and the package name as a Component.

In the live walk, a Space named for the nginx entry's id and a Component named bitnami-nginx already existed, so the walk chose its own names. The --component flag sets the Component label the upload writes on the Space, which is the package name when you omit it.

The cub installer plugin reads your organization from CUB_CONTEXT and ignores --context. If you use a context other than your default, export CUB_CONTEXT first, or the plugin works in your default organization.

# sign in; steps 3 to 5 write to your ConfigHub organization
$ cub auth login

# upload step 1's directory as a Space of Units, under names you choose
$ cub installer upload --work-dir ./velero-velero-12-1-0-default --space <your-space> --component <your-component>

# list the Units the upload created
$ cub unit list --space <your-space>

4. Deploy it Not run for this entry

No delivery run is recorded for this entry. Argo CD has not run, Flux has not run, and kubectl has not run. The commands name the Target workshop/target, which cub cluster up --name workshop creates on a local kind cluster with Argo CD. Use your own Target for a real destination. Read the log of the live walk on 2026-10-08.

Use the Space name you chose in step 3. The delete command is needed because the cloned installer-record Unit carries the Target and Argo CD v3.5.4 cannot read it, a defect seen on cub v0.8.7 and server v0.8.9.

Without that line the walk deployed nothing and Argo CD showed Unknown, while every cub command exited 0. The walk ran the four commands in this order and did not try them without the first publish.

ConfigHub shows nothing when Argo CD fails to read a Release. Run kubectl -n argocd get applications.argoproj.io and read the Sync column, because Healthy alone is not a pass. Argo CD took between 18 seconds and about 5 minutes to read a Release on a cluster made without argobot.

The walk made its cluster with cub cluster up --no-argobot. That command creates two Spaces, a Worker, a Target and a Trigger, opens ports 30010 to 30019 on the machine, and installs Argo CD from an unpinned upstream manifest.

Removing the ConfigHub side does not remove the workload. In the walk, deleting the Application Unit and the Spaces left the Application and its pods running, because the root Application does not prune.

# clone the base onto a Target as a dev variant
$ cub variant create dev <your-space> --target workshop/target --space-pattern "template:<your-space>-dev"

# publish the Release that the cluster's Argo CD pulls
$ cub release publish <your-space>-dev

# delete the installer record, which Argo CD cannot read
$ cub unit delete --space <your-space>-dev installer-record

# publish again without it
$ cub release publish <your-space>-dev

5. Promote a change Not run for this entry

No promotion is recorded for this entry. Promotion carries a change in the base to the dev variant. The base changes when you edit a Unit or upload a newer version into the same Space. Read the log of the live walk on 2026-10-08.

The promotion changes the dev Space and publishes nothing. It also adds the installer-record Unit back with the Target. The change reaches the cluster only after the delete and the publish.

The preview lists the whole installer record as added. In the walk, the preview of a one-label change to gpu-operator ran to 405 lines, and about 400 of them were that record.

# preview what the dev variant would take from the base
$ cub variant promote <your-space>-dev --dry-run -o mutations

# promote once you have read the preview
$ cub variant promote <your-space>-dev --change-desc "Pull the reviewed base forward"

# delete the installer record that the promotion adds back
$ cub unit delete --space <your-space>-dev installer-record

# publish the Release that carries the change
$ cub release publish <your-space>-dev