argo-cd/argo-workflows
This page exists so you do not have to guess your way through this Helm chart. It shows the useful ways we know how to run it, the Kubernetes YAML each choice produces, and the evidence behind the current claim.
Start by choosing a base variant. A base variant is a supported Helm configuration such as default, no-CRDs, existing Secret, HA, or server-only.
The page does not claim every values combination for this chart. It shows the supported base variants we have recorded, what problem each one solves, and the chart-specific work that still needs a decision.
Use it to choose the first useful base variant, read the exact objects, catch prerequisites or classic errors, and see what is proven before you install or promote anything.
Pass means backed by evidence. Watch or blocked means the limit is named so you can decide what to do next.
ecosystem: find this chart on Artifact Hub · Helm docs - discovery and tooling live upstream; this page adds the proof.
proof-grade / machine-proof-only page for argo-cd/argo-workflows@1.0.14.
cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/argo-cd-argo-workflows:1.0.14 --base default --work-dir ./argo-cd-argo-workflows-1-0-14-default --non-interactive --namespace default
Three ways this page helps you test
The same three things hold for every package in the catalog, Helm charts and OCI packages alike. Why this makes configuration easier to test.
The package fixes and checks almost everything at build time. What you set is small and typed.
Render parity, live install, and delivery, recorded as receipts you can open.
The page names the work and says which delivery path has actually run.
What To Use
default base variant: 19 rendered objects · 2 images · 1 lifecycle route · 5/6 proof lanes passing. Every number is extracted from committed data.
defaultRecommended first base variant
3Candidate base variants
see basesStart-base status
not-reviewed-for-productionProduction disposition
The recipe/package proof exists and useful variants exist, but this chart has not been promoted into the public catalog.
| Question | Answer |
|---|
| Catalog level | proof-grade / machine-proof-only |
| Chart version | 1.0.14 |
| Installer package OCI | oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/argo-cd-argo-workflows:1.0.14 |
| OCI publication status | publication receipt recorded |
| Latest upstream seen | not checked |
| Candidate base variants | default;controller-default-reviewed;minimal-crds |
| Not yet enabled | - (no open gap: recommended capabilities built or n/a; quirks modeled - Level 2) |
| Namespace | default |
Where This Chart's Settings Come From
Helm values define each base render. ConfigHub changes begin after upload and are recorded against the rendered objects. Secrets, CRDs, hooks, and setup jobs are listed separately because they are install work, not hidden settings. Live cluster state is observed separately and does not silently become the desired configuration.
| Base variant | Helm values | ConfigHub changes | Install work |
|---|
| default | effective-values.yaml | None in the catalog base. Later edits appear in ConfigHub Unit revision history or a derived variant. | 8 prerequisites and 1 hook or setup route recorded. |
| controller-default-reviewed | effective-values.yaml | None in the catalog base. Later edits appear in ConfigHub Unit revision history or a derived variant. | 8 prerequisites and 1 hook or setup route recorded. |
| minimal-crds | effective-values-minimal-crds.yaml | None in the catalog base. Later edits appear in ConfigHub Unit revision history or a derived variant. | 1 hook or setup route recorded. |
Upgrade rule: if a new Helm render and a ConfigHub revision both change the same field, review the overlap before promotion. The values profile shows the Helm side; Unit revision history shows the ConfigHub side.
Read the full values-versus-ConfigHub rule.
What A Base Variant Records
A base variant solves the first Helm problem: which chart inputs should we use, and what Kubernetes objects do they produce? Each base variant records the Helm chart version, values profile, namespace, release name, capability profile, source lock, generated output, and evidence lanes.
The default base-variant record joins those Helm facts to the literal objects, remaining target inputs, hooks and CRDs, apply policy, and OCI handoffs. It is the short record to open when you need the whole base rather than only its rendered YAML.
Open the full rendered YAML to read the actual manifest output. Then use the render intent, receipts, and chart-extras section to see the inputs, checks, and CRD/hook/setup decisions around it.
If your values file creates a new useful operating shape, it should become another base variant with its own recorded inputs and checks. If it only changes an already-rendered field after upload, it belongs in a derived ConfigHub variant that can be reviewed and kept through upgrades.
| Key | Where to look first | What it means |
|---|
| Package users pull | oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/argo-cd-argo-workflows:1.0.14 | The installer package OCI ref for this chart version. After publication, it contains the available bases and package metadata. Public catalog package refs are published in Google Artifact Registry with anonymous read access. No ConfigHub account or Google registry login is needed for the local setup path. |
| Required before apply | 8 CRDs
Included in the OCI package as prerequisites/target-facts/default-crds.yaml. It refreshes the locked CRDs with the chart's server-side, force-conflicts apply mode. The generated try script runs this step before the workload and waits for every CRD to become established. | External resources the recommended base variant expects, such as an existing Secret, namespace, CRD, or target fact. |
| Kubernetes objects | full rendered YAML | The full YAML captured from this base variant. It is the output of the render. |
| Render record | default render intent | The Helm inputs and evidence links that explain how the output was produced. |
| Base variant record | default base-variant record | The source-neutral record that joins the Helm record, literal objects, remaining inputs, routes, policy, and OCI status. |
| Hooks, CRDs, and setup work | this page's chart-extras section | The route decisions for non-plain-YAML work: hooks, CRDs, generated Secrets, setup jobs, target facts, or blockers. |
Choose base variant
Pick the supported Helm configuration for this chart: default, no-CRDs, existing Secret, HA, server-only, or another listed option.
Record inputs
Keep the values profile, namespace, release name, source lock, default render intent, full YAML output, package base, proof lanes, and route context together.
Handle chart extras
CRDs, hooks, setup jobs, external Secrets, target facts, and webhook certificates are recorded as chart-specific choices. Some are included in a base variant, some need a setup step, and some are blocked until there is a safe path.
How render intents work · All generated render intents · All base variant records
How To Try This Chart
Start with default unless a card below explains that another base variant is a better first path. If a card says review or preparation is needed, treat that as a real limit rather than a ready install.
Package image
oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/argo-cd-argo-workflows:1.0.14
publication receipt recorded
Public catalog package refs are published in Google Artifact Registry with anonymous read access. No ConfigHub account or Google registry login is needed for the local setup path.
Recommended first command
cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/argo-cd-argo-workflows:1.0.14 --base default --work-dir ./argo-cd-argo-workflows-1-0-14-default --non-interactive --namespace default
Or run the whole sequence as one script, prerequisites included: try.sh (render and apply, no account) · confighub.sh (render and upload to your ConfigHub Space).
You should see something like this
New to cub? Install the cub CLI first. You can pull and render public catalog packages without an account. Commands that save or change ConfigHub data require you to sign in.
What this command does. cub installer is a released, open-source plugin for the cub CLI. cub installer setup pulls a catalog package and writes its Kubernetes files locally. It does not apply those files to a cluster; use kubectl, Argo CD, or Flux for delivery. The generated scripts stop before doing any work when the plugin or kustomize is missing.
cub installer setup ...
rendered manifests written under <work-dir>
use the chart option cards below to check pass, watch, blocked, and prerequisites
Current status: Available in the catalog · Reason: Server side promotion receipt passed
Argo Workflows CRDs
The normal Helm install runs a hook that downloads eight full CRD files from GitHub and applies them before the controller and server. Those CRDs are not in the ordinary rendered release, so another delivery path has to replace that step deliberately.
The catalog package contains the exact eight files used by this chart version. Their source URLs and digests are recorded. The no-account script applies them with the same server-side, force-conflicts mode as the Helm hook, waits for them to become established, and then applies the ordinary objects.
| Choice | What happens |
|---|
default | Uses the full upstream CRD schemas. The package applies the locked CRD bundle before the workloads. |
minimal-crds | Renders eight smaller CRDs as ordinary objects. This avoids the hook but uses looser schemas that preserve unknown fields. |
| Argo CD or Flux | Ordering still needs its own controller-specific proof. The direct package result does not claim either controller ran this step automatically. |
Two clean kind clusters checked the direct path: Helm ran its real hook in one, the catalog package ran its CRD action in the other, all eight live CRD specifications matched, the 19 ordinary objects matched, and both workloads became ready.
Read the plain-English guide and repeat the test · Open the receipt
Base Variants And Options
Each card is one available way to use this chart in the catalog. Some cards are runnable base variants. Others are candidate paths, derived variants, or review notes that explain what still has to be prepared.
Check labels: R = render parity, C = ConfigHub proof, L = local cluster, Y = lifecycle actions, G = GitOps/OCI, P = live Helm-vs-ConfigHub parity, K = two-cluster kind parity, V = variant promotion.
4 matrix rows for argo-cd/argo-workflows@1.0.14 · open the full matrix
Upstream chart source
- Status
- Available in the catalog
- How to run
- This is the upstream chart source. Choose a base card below before running the installer.
- Evidence
- Pinned chart source and dependency lock
- Hooks/actions
- 1 source hook; hook route: observed; live action receipt: yes
- Who runs actions?
- read the route receipt before delivery
- Next
- Choose or create an F2 base before rendering or deploying
- Reason
- Source rows are upstream chart inputs; Not server side promotion evidence
Rn/aCn/aLn/aYn/aGn/aPn/aKn/aVn/a
catalog · source repo
F2a honest default base
- Status
- Available in the catalog
- Helm values
- effective-values.yaml
- ConfigHub changes
- None in this catalog base. After upload, read Unit revision history or the derived variant.
- How to run
cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/argo-cd-argo-workflows:1.0.14 --base default --work-dir ./argo-cd-argo-workflows-1-0-14-default --non-interactive --namespace default- Scripts
- try.sh renders, settles the prerequisites in order, and applies with kubectl; confighub.sh renders and uploads to your ConfigHub Space.
- Evidence
- Live helm vs confighub parity
- Hooks/actions
- 1 source hook; hook route: observed; live action receipt: yes; 1 recorded lifecycle route
- Who runs actions?
- You or your delivery pipeline (1); the full record shows which delivery paths have receipts
- Lifecycle record
- 1 chart-specific lifecycle route is recorded. The full record separates direct, Argo CD, and Flux handling and says which paths have actually run. Open the full record.
- Prerequisites
- 8 prerequisites are declared for this base. Each prerequisite says whether it must be checked before render or before apply.
- Next
- Run catalog promotion review
- Reason
- Server side promotion receipt passed
RyesCyesLnoYtodoGyesPyesKyesVyes
catalog · variant · full YAML · render intent · base record · package base · receipt · source repo
F2b
controller-default-reviewed
Base
Runnable base variant
- Status
- Available in the catalog
- Helm values
- effective-values.yaml
- ConfigHub changes
- None in this catalog base. After upload, read Unit revision history or the derived variant.
- How to run
cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/argo-cd-argo-workflows:1.0.14 --base controller-default-reviewed --work-dir ./argo-cd-argo-workflows-1-0-14-controller-default-reviewed --non-interactive --namespace default- Scripts
- try.sh renders, settles the prerequisites in order, and applies with kubectl; confighub.sh renders and uploads to your ConfigHub Space.
- Evidence
- Live helm vs confighub parity
- Hooks/actions
- 1 source hook; hook route: candidate-route; live action receipt: todo; 1 recorded lifecycle route
- Who runs actions?
- Not automated yet (1); the full record shows which delivery paths have receipts
- Lifecycle record
- 1 chart-specific lifecycle route is recorded. The full record separates direct, Argo CD, and Flux handling and says which paths have actually run. Open the full record.
- Prerequisites
- 8 prerequisites are declared for this base. Each prerequisite says whether it must be checked before render or before apply.
- Next
- Run catalog promotion review
- Reason
- Server side promotion receipt passed
RyesCyesLnoYtodoGyesPyesKyesVyes
catalog · variant · full YAML · render intent · base record · package base · receipt · source repo
Runnable base variant
- Status
- Available in the catalog
- Helm values
- effective-values-minimal-crds.yaml
- ConfigHub changes
- None in this catalog base. After upload, read Unit revision history or the derived variant.
- How to run
cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/argo-cd-argo-workflows:1.0.14 --base minimal-crds --work-dir ./argo-cd-argo-workflows-1-0-14-minimal-crds --non-interactive --namespace default- Scripts
- try.sh renders, settles the prerequisites in order, and applies with kubectl; confighub.sh renders and uploads to your ConfigHub Space.
- Evidence
- Live helm vs confighub parity
- Hooks/actions
- 1 source hook; hook route: observed; live action receipt: yes; 1 recorded lifecycle route
- Who runs actions?
- Kubernetes or the delivery controller (1); the full record shows which delivery paths have receipts
- Lifecycle record
- 1 chart-specific lifecycle route is recorded. The full record separates direct, Argo CD, and Flux handling and says which paths have actually run. Open the full record.
- Prerequisites
- This base has not yet been reviewed for required Secrets, CRDs, namespaces, values, storage services, external APIs, or target topology. Record what it needs, or record that nothing extra is required.
- Next
- Run catalog promotion review
- Reason
- Server side promotion receipt passed
RyesCyesLyesYyesGyesPyesKyesVyes
catalog · variant · full YAML · render intent · base record · package base · receipt · source repo
Images This Chart Pulls
Every reference below comes from the reviewed rendered output. What you see is what the cluster pulls. These references are data: you can change a registry or pin a digest with a recorded edit, and prove the change landed in every environment.
| Base variant | Images |
|---|
| default | quay.io/argoproj/argocli:v4.0.5
quay.io/argoproj/workflow-controller:v4.0.5 |
| controller-default-reviewed | quay.io/argoproj/argocli:v4.0.5
quay.io/argoproj/workflow-controller:v4.0.5 |
| minimal-crds | properties:
quay.io/argoproj/argocli:v4.0.5
quay.io/argoproj/workflow-controller:v4.0.5
type: string |
First-Run Caveats
Some chart paths need a small preparation step before the cub path feels as smooth as Helm. We show those steps here so the first run does not surprise you.
| Caveat | What to do |
|---|
| Universal caveats | Use declared inputs or bases instead of Helm --set. For direct delivery, define pruning and field-conflict behavior. Use Argo CD or Flux when that controller path is recorded for the selected preset. |
| Shared placeholder password | No shared placeholder password caveat recorded for this chart. |
| CRD first-ordering | Yes. 8 CRDs must exist first. The public package contains the bootstrap, and its generated try.sh applies it and waits for the CRDs before installing the main objects. |
Open the all-chart adoption caveats · Helm to cub migration · cub deployment path
Operator Playbooks And Fact Sheet
This is the quick route for a human or agent: which operating playbook applies, what the current user-facing answer is, and what the next proof or product action would add.
| Fact | Current chart-level route |
|---|
| User status | works-with-operator-review |
| Can I use it? | not-yet-public-catalog-proof-ready |
| First base | minimal-crds |
| Installer package OCI | oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/argo-cd-argo-workflows:1.0.14 |
| Current proof | proof-grade-ready-for-promotion-review (render parity 3/3, local live 1/3, live parity 3/3) |
| Coverage | partial |
| User must provide | nothing beyond a cluster and namespace |
| ConfigHub/installer absorbs | exact rendered objects with render parity and receipts; extension slots routed to reviewed bases |
| Next action | run catalog promotion review |
The source data lives in chart skills and chart evidence router.
Proof Lanes
Each lane proves a different outcome. Missing or non-pass rows are backlog or target-fit evidence; they do not change the render-parity result.
How much is proven, and what more testing would add: Fully proven: Render parity, ConfigHub proof, GitOps/OCI live, Live Helm-vs-ConfigHub, Two-cluster kind. Proven on some bases: Local live.
| Lane | Status across bases |
|---|
| Render parity | yes: 3/3 |
| ConfigHub proof | yes: 3/3 |
| Local live | no: 2/3; yes: 1/3 |
| GitOps/OCI live | yes: 3/3 |
| Live Helm-vs-ConfigHub | yes: 3/3 |
| Two-cluster kind | yes: 3/3 |
| Base | Readiness | Render | ConfigHub | Local live | GitOps/OCI | Live parity | Two-cluster kind |
|---|
| default | real | yes | yes | no | yes | yes | yes |
| controller-default-reviewed | real | yes | yes | no | yes | yes | yes |
| minimal-crds | real | yes | yes | yes | yes | yes | yes |
Quirks And Inputs
exact rendered objects with render parity and receipts; extension slots routed to reviewed bases
| Field | Value |
|---|
| Known quirks | extension-slots |
| User must provide | nothing beyond a cluster and namespace |
| ConfigHub absorbs | exact rendered objects with render parity and receipts; extension slots routed to reviewed bases |
| Extension slots | tpl-powered values |
| Extension route | keep empty in supported bases, or make a reviewed installer base when populated |
Hooks, CRDs, And Setup Work
Some Helm charts need work before, during, or after apply: CRDs, hooks, setup jobs, webhook certificates, migrations, generated Secrets, or checks. For each chart, the catalog should make the choice clear: include it in the base variant, split it into a separate base variant, run a setup step, use a GitOps action where evidence exists, require an existing target resource, or block it when there is no safe default.
What each base needs before apply
These requirements come from the same base definition as the rendered objects. The render intent keeps the chart inputs, required Secrets or CRDs, lifecycle routes, and evidence together.
| Base variant | Required resource | How to provide it | Full record |
|---|
| default | 8 CRDs | Included in the OCI package as prerequisites/target-facts/default-crds.yaml. It refreshes the locked CRDs with the chart's server-side, force-conflicts apply mode. The generated try script runs this step before the workload and waits for every CRD to become established. | full render intent |
| controller-default-reviewed | 8 CRDs | Included in the OCI package as prerequisites/target-facts/controller-default-reviewed-crds.yaml. It refreshes the locked CRDs with the chart's server-side, force-conflicts apply mode. The generated try script runs this step before the workload and waits for every CRD to become established. | full render intent |
If no route is shown, that does not prove the upstream chart has no hooks. It means the public catalog has no chart-specific action to show yet; check the matrix or send a problem chart if hook behavior should be modeled. Direct apply, Argo CD, Flux, and upgrade implementations are tracked separately. One passing implementation does not prove the others.
controller-default-reviewed: package applies 8 CRDs first
| Hook or setup step | Who handles it? | Argo CD mapping | Flux mapping | Change for this variant |
|---|
crd-install (preflight-or-presync-crd-apply)
full CRDs required before workflow-controller and server can start; hook uses server-side apply because full CRDs exceed client-side apply annotation limits | Prerequisite - run the generated package script before the workloads | PreSync · sync-wave -2 · ServerSideApply | HelmRelease .spec.install.crds=Create (or apply CRDs first) | packaged-action - the package carries the 8 CRDs and its generated script applies them before the workload; this base still needs its own live route receipt |
Evidence: data/hook-route-candidates/candidates.csv
Next: direct full-CRD package route is proven; next prove controller-run ordering under Argo CD and Flux and test a cross-version CRD upgrade
default: package applies 8 CRDs first
| Hook or setup step | Who handles it? | Argo CD mapping | Flux mapping | Change for this variant |
|---|
crd-install (preflight-or-presync-crd-apply)
The controller and server require the Argo Workflows APIs. Helm normally downloads and applies the full CRDs in a hook before those workloads start. | Handled - the generated package script applies the CRDs first | PreSync · sync-wave -2 · ServerSideApply | HelmRelease .spec.install.crds=Create (or apply CRDs first) | resolved - the package carries and applies the 8 CRDs before the workload (observed live) |
Evidence: data/hook-route-candidates/selected-routes/argo-cd-argo-workflows-default.yaml
docs/demo/hooks-crds/argo-workflows.md
data/hook-route-candidates/argo-cd-argo-workflows.yaml
recipes/argo-cd/argo-workflows/1.0.14/variants/default/variant.yaml
recipes/argo-cd/argo-workflows/1.0.14/upstream/full-crds/argoproj.io_workflows.yaml
packages/argo-cd/argo-workflows/1.0.14/prerequisites/target-facts/default-crds.yaml
runs/live-kind-parity/argo-cd-argo-workflows-default/receipt.yaml
runs/live-helm-confighub-compare/argo-cd-argo-workflows-default/receipt.yaml
minimal-crds
| Hook or setup step | Who handles it? | Argo CD mapping | Flux mapping | Change for this variant |
|---|
crd-install (self-contained-crd-base)
Argo Workflows default full CRDs are installed through a Helm hook using server-side apply; this base chooses the self-contained minimal-CRD route instead. | Your applier - must apply CRDs before dependent objects | no extra hook - keep CRDs before dependent objects | no extra hook - make sure CRDs are applied before workloads | resolved - this base installs the required CRDs (observed live) |
Evidence: data/hook-route-candidates/selected-routes/argo-cd-argo-workflows-minimal-crds.yaml
data/hook-route-candidates/argo-cd-argo-workflows.yaml
recipes/argo-cd/argo-workflows/1.0.14/variants/minimal-crds/variant.yaml
recipes/argo-cd/argo-workflows/1.0.14/revisions/minimal-crds/r001/receipts/install-gate.yaml
runs/next80-local-kind/argo-cd-argo-workflows-1.0.14-minimal-crds/observation-receipt.yaml
runs/argo-workflows-minimal-crds-confighub-proof/latest/confighub-proof-receipt.yaml
runs/live-helm-confighub-compare/argo-cd-argo-workflows-minimal-crds/receipt.yaml
runs/live-kind-parity/argo-cd-argo-workflows-minimal-crds/receipt.yaml
Production Boundary
A green render or local live result is not a production support claim. Production support is target-scoped and uses the support-decision artifact when present.
| Field | Value |
|---|
| Production disposition | not-reviewed-for-production |
| Target-scoped support decision | not recorded |
| Supported base | |
| Target scope | |
| Accepted dispositions | none recorded |
| Open policy dispositions | none recorded for this policy checklist |
| Next action | run catalog promotion review |