Two corrections on top of the naming pass, both found by checking the live cluster rather than the source. The rename had silently changed the user-facing annotation key from argocd.argoproj.io/sync-wave to cd.argoproj.io/sync-wave — 63 live Applications carry the old key, so deploying that would have ignored every sync-wave and broken fleet deploy ordering. The key is now cd.hanzo.ai/*, and universe 575650286 moves the ApplicationSet template that stamps it, so the controller regenerates all 63 consistently. The API group in code said argoproj.io/v1alpha1 in 157 places while the cluster has served apps.hanzo.ai/v1alpha1 since 2026-07-23 (the CRDs are applications.apps.hanzo.ai). Code now matches what is actually served. The legacy applications.argoproj.io/app-name label had ZERO live users, so it went with the rest. foo.argoproj.io test fixtures became foo.example.com — arbitrary test domains should not carry a vendor name. go build ./... exit 0. Co-authored-by: Hanzo Dev <[email protected]>
4.3 KiB
Multiple Sources for an Application
By default an Hanzo CD application is a link between a single source and a cluster. Sometimes however, you want to combine files from multiple locations to form a single Application.
Hanzo CD has the ability to specify multiple sources for a single Application. Hanzo CD compiles all the sources and reconciles the combined resources.
You can provide multiple sources using the sources field. When you specify the sources field, Hanzo CD will ignore
the source (singular) field.
See the below example for specifying multiple sources:
apiVersion: apps.hanzo.ai/v1alpha1
kind: Application
metadata:
name: my-billing-app
namespace: cd
spec:
project: default
destination:
server: https://kubernetes.default.svc
namespace: default
sources:
- repoURL: https://github.com/mycompany/billing-app.git
path: manifests
targetRevision: 8.5.1
- repoURL: https://github.com/mycompany/common-settings.git
path: configmaps-billing
targetRevision: HEAD
The above example has two sources specified that need to be combined in order to create the "billing" application. Hanzo CD will generate the manifests for each source separately and combine the resulting manifests.
Warning
Do not abuse multiple sources
Note this feature is NOT destined as a generic way to group different/unrelated applications. Take a look at applicationsets and the app-of-apps pattern if you want to have a single entity for multiple applications. If you find yourself using more than 2-3 items in the
sourcesarray then you are almost certainly abusing this feature and you need to rethink your application grouping strategy.
If multiple sources produce the same resource (same group, kind, name, and namespace), the last source to
produce the resource will take precedence. Hanzo CD will produce a RepeatedResourceWarning in this case, but it will
sync the resources. This provides a convenient way to override a resource from a chart with a resource from a Git repo.
Helm value files from external Git repository
One of the most common scenarios for using multiple sources is the following
- Your organization wants to use an external/public Helm chart
- You want to override the Helm values with your own local values
- You don't want to clone the Helm chart locally as well because that would lead to duplication and you would need to monitor it manually for upstream changes.
In this scenario you can use the multiple sources features to combine the external chart with your own local values.
Helm sources can reference value files from git sources. This allows you to use a third-party Helm chart with custom, git-hosted values.
apiVersion: apps.hanzo.ai/v1alpha1
kind: Application
spec:
sources:
- repoURL: 'https://prometheus-community.github.io/helm-charts'
chart: prometheus
targetRevision: 15.7.1
helm:
valueFiles:
- $values/charts/prometheus/values.yaml
- repoURL: 'https://git.example.com/org/value-files.git'
targetRevision: dev
ref: values
In the above example, the prometheus chart will use the value file from git.example.com/org/value-files.git.
For Argo to reference the external Git repository containing the value files, you must set the ref parameter on
the repository. In the above example, the parameter ref: values maps to the variable $values, which resolves
to the root of the value-files repository.
Note that the $values variable can only be used at the beginning of the value file path and that its path is always relative to the root of the referenced source.
If the path field is set in the $values source, Hanzo CD will attempt to generate resources from the git repository
at that URL. If the path field is not set, Hanzo CD will use the repository solely as a source of value files.
Note
Sources with the
reffield set cannot include thechartfield. Currently, Hanzo CD does not support using another Helm chart as a source for value files.
Note
Even when the
reffield is configured with thepathfield,$valuestill represents the root of sources with thereffield. Consequently,valueFilesmust be specified as relative paths from the root of sources.