Argo CD / Generated systems and controlled recovery / Lesson 14

Multiple sources and composite release identity

Bind every source revision and value dependency to the candidate being reviewed.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain sources versus a single source and external Helm values references.
Review overlapping resource precedence without treating multi-source as an application grouping shortcut.

One Application can have a composite input

The sources field can combine supported inputs for one Application. That does not mean it is the best way to group many unrelated applications. Parcel might consume a chart from one source and controlled values from another, with separate writers and revision lifecycles. Each source contributes to desired output or referenced inputs under documented rules. When sources is used, review the actual source selection model instead of assuming a leftover singular source still determines everything. The release identity becomes a vector of resolved inputs, not one convenient commit label.

An external values reference has specific syntax

The fragment below references a Git values source from a synthetic chart source using the documented $values prefix form. The ref name defines that prefix, and the path is resolved under the referenced source’s contract. The values source shown has no manifest path, so it is intended as values input rather than another generated workload set. Both repository domains are nonworking teaching addresses, and the chart version is an invented example label, not a published package or verified pin. Nothing is fetched or rendered.

yaml A synthetic chart-and-values source fragment

sources:
  - repoURL: https://charts.example.invalid
    chart: parcel
    targetRevision: "1.2.3"
    helm:
      valueFiles:
        - $values/env/lab.yaml
  - repoURL: https://example.invalid/parcel-values.git
    targetRevision: lab-values-ref
    ref: values

This partial Application is not executed. It requires supported source semantics, approved repositories, actual resolved identities, and a real chart before any rendering or policy claim is meaningful.

Repeated resource identities need an explicit decision

When multiple sources produce the same resource identity, the documented later-source precedence can take effect and generate a repeated-resource warning. Do not treat that warning as harmless formatting. Review which source owns the object and why overriding it is intended. Changes to source order can change desired resources without modifying the chart itself. A shared current manifest does not eliminate future tracking, pruning, field-management, or authorization concerns. Keep unrelated application grouping at an appropriate abstraction rather than creating a large opaque source list.

Bind the complete revision vector

The complete local model compares an approved pair of source revisions with the candidate’s pair. It rejects a values revision change even though the chart revision is unchanged. These labels are synthetic and do not authenticate actual sources. Real evidence also includes toolchain, parameters, dependency resolution, and artifact identities where relevant. The model isolates one invariant: every material input belongs to the decision. A successful test for yesterday’s values cannot be combined casually with today’s chart or target configuration.

python A synthetic composite-revision check

approved = {"chart": "chart-lab-r2", "values": "values-lab-r5"}
candidate = {"chart": "chart-lab-r2", "values": "values-lab-r6"}
print(approved == candidate)
print(sorted(k for k in approved if approved[k] != candidate.get(k)))

Expected output

False
['values']

The dictionaries contain no real commits or package digests. No repository, registry, chart renderer, Application, or cluster is read.

Each source adds another influence boundary

Project policy, repository authentication, writer trust, and renderer behavior must cover every source. A narrowly reviewed chart can still be altered materially by broad values or an overriding manifest source. Source changes can also trigger reapplication of resources associated with another unchanged source, so a disabled self-heal flag is not a universal promise that live edits persist. Preserve a single reviewable composite candidate and a recovery plan for mixed-source changes. If one source is unavailable, diagnose generation rather than assuming the unchanged sources form a valid partial desired state.

Common errors and fixes

Only the chart revision is recorded for a chart-plus-values release.

Why it happens: A material second input is omitted from candidate identity.
How to fix it: Retain every resolved source and relevant rendering parameter.
Prevent it next time: Bind approvals and tests to the complete input vector.

Source ordering changes without reviewing repeated identities.

Why it happens: Precedence is treated as irrelevant list formatting.
How to fix it: Inspect overlapping resources and the intended owner before reordering.
Prevent it next time: Keep warnings and source-order changes reviewable.

Many unrelated applications are combined into one opaque sources list.

Why it happens: Input composition is used as a substitute for clear application boundaries.
How to fix it: Choose an appropriate grouping or generation model with explicit ownership.
Prevent it next time: Review failure, deletion, and authorization scope before composition.

Check your understanding

1. The chart is fixed but the values source advances. Is the candidate unchanged?

Show worked solution

No. Values can alter names, images, scope, replicas, and other rendered behavior. Review the resolved composite identity and generated output. A fixed chart version alone does not establish equal desired resources.

2. Two sources emit the same Service. Why inspect a repeated-resource warning?