This small example shows the same setup job running from one OCI package through Argo CD, Flux, and direct apply.
Start here when you open this Space in Hub. This page explains the problem this example is meant to show, what to inspect, why it matters, and where the evidence lives.
Why this example exists
Some charts need a setup or migration Job as well as the main workload. Running that work inside one Helm command makes it difficult to see, repeat, or audit.
This example moves the Job into the delivery plan. It proves the mechanism on a small fixture before we apply the same pattern to a complex chart.
What this example shows
- The workload and setup Job are stored as ordinary, reviewable Kubernetes objects.
- Argo CD, Flux, and the direct script each ran the Job and recorded its completion.
- The route is marked automatic only for this tested fixture and these three delivery paths.
Where each setting comes from
| Place | What this Space records |
|---|---|
| Starting configuration | Open the upstream Space or source link named on this page. That is the configuration this Space started from. |
| ConfigHub changes | Open Unit revision history. It records changes made after the starting configuration was saved. |
| Install work | Use the linked chart or route evidence for required Secrets, CRDs, hooks, setup jobs, and target facts. |
| Live cluster | Use target observations to compare the cluster with the reviewed Units. A live-only edit is drift until it is recorded or removed. |
If an upstream change and a local ConfigHub revision touch the same field, review the overlap before promotion.
What to inspect in Hub
- This README.
- The workload and setup Job Units.
- The LifecycleRoute Unit that links the delivery receipts.
Evidence and source
Limits
- This result does not make every Helm hook automatic. Each real chart still needs a recorded, chart-specific decision.