Argo Workflows: install the right CRDs before the workloads

The chart's default configuration does not put its full Custom Resource Definitions (CRDs) in the ordinary manifest output. During install and upgrade, a Helm hook downloads eight CRD files from GitHub and applies them before the controller and server start. The hook uses Kubernetes server-side apply with forced conflict resolution because the full schemas are too large for the client-side apply annotation.

That sequence works in Helm, but it creates three questions for any other delivery path:

Which exact CRD files should be used?
Who applies or upgrades them before the workloads?
How can a reviewer check that the alternative path produced the same result?

What the catalog package does

The default package base keeps the chart's normal full-CRD behavior without requiring an install-time download from GitHub.

The package contains the eight full CRD files used by argo-workflows@1.0.14.
Each source URL and SHA-256 digest is recorded in the base variant.
The generated no-account script applies the CRDs with kubectl apply --server-side --force-conflicts before it applies the controller and server objects.
Running the same step before an upgrade refreshes the CRDs in the same phase as Helm's pre-upgrade hook.
The script waits for every CRD to become established before it applies the workloads.

This is a chart-specific replacement for one Helm hook. It is not a claim that one generic hook translator can safely handle every chart.

Try the default path

Use a disposable Kubernetes cluster:

bash <(curl -fsSL \
  https://confighub.github.io/helm-expt/site/sh/argo-cd-argo-workflows-1-0-14/default/try.sh)

The script first writes the package and rendered objects under ./argo-cd-argo-workflows-1-0-14-default. Read those files before the first kubectl apply step if you want to inspect exactly what will run.

The same package can be rendered without touching a cluster:

New to cub? Install the cub CLI first. Public catalog packages pull and render anonymously, and you sign in only once a command saves or changes ConfigHub data.

Here is what the command does. cub installer is an open-source plugin for the cub CLI. cub installer setup pulls a catalog package and writes its Kubernetes files locally, leaving delivery to kubectl, Argo CD or Flux. The generated scripts stop before doing any work when the plugin or kustomize is missing.

cub installer setup \
  --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/argo-cd-argo-workflows:1.0.14@sha256:21c5bc5c0500c1bc85d02b44ba4e4321101f58f5625b6acce22c78ba815205c2 \
  --base default \
  --work-dir ./argo-workflows-default \
  --non-interactive \
  --namespace default

The CRD bundle is in:

./argo-workflows-default/package/prerequisites/target-facts/default-crds.yaml

The ordinary rendered objects are in:

./argo-workflows-default/out/manifests/

What was checked

The live comparison used two clean kind clusters.

Normal Helm ran its real pre-install hook.
The catalog package applied its locked CRD bundle before the ordinary rendered objects.
All eight live CRD specifications had matching SHA-256 digests.
The 19 ordinary chart objects matched semantically.
The workflow controller and server became ready in both clusters.
Both clusters were deleted after the run.

The receipt is runs/live-kind-parity/argo-cd-argo-workflows-default/receipt.yaml.

The smaller alternative

The minimal-crds base makes a different, explicit choice. It renders eight smaller CRDs as ordinary Kubernetes objects and does not need the full-CRD hook. Those CRDs preserve unknown fields instead of carrying the full OpenAPI schemas.

Use that base when the smaller schema is acceptable and you want the CRDs to travel with the ordinary rendered release:

bash <(curl -fsSL \
  https://confighub.github.io/helm-expt/site/sh/argo-cd-argo-workflows-1-0-14/minimal-crds/try.sh)

The minimal and full CRDs are not interchangeable proof. Choose the behavior you want and keep that choice with the base variant.

What remains

The direct package path is proven for a fresh install. It also contains the same CRD action needed before an upgrade, but a cross-version upgrade has not yet been tested.

Argo CD and Flux need their own ordering proof before this page can claim that either controller runs the full-CRD action automatically. Until then, use the generated direct script, make the CRDs a separately managed prerequisite, or choose the minimal-crds base.

This evidence is not a production support statement. A production decision still needs the target Kubernetes version, upgrade policy, CRD ownership, and recovery procedure.