Argo CD / Desired state and evidence foundations / Lesson 3

Source generation and reproducible manifest inputs

Trace a source revision through path, values, tool versions, and generated resource sets.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish generation failure from sync failure.
Identify mutable rendering inputs beyond a Git commit.

Desired resources are generated before comparison

Argo CD needs a desired resource set before it can compare or synchronize it. A Git directory, Helm chart, Kustomize overlay, or configured plugin can introduce different rendering contracts. Parcel’s Git revision may contain a chart whose output also depends on values and tool behavior. A manifest-generation error means the desired set is unavailable or invalid under that contract; it is not evidence that Kubernetes rejected a resource. Diagnose the source and renderer boundary before changing cluster permissions or repeatedly requesting sync.

A commit is important but not always sufficient

Record repository identity, resolved revision, path, relevant values or parameters, tool versions, and any external dependencies used during generation. A mutable chart dependency or random template value can change output while the top-level Git revision stays fixed. Avoid assuming that every renderer is hermetic. Reproducibility requires declared inputs and controlled acquisition, while promotion requires continuity of the intended generated candidate. A stable Application name can hide a changed render configuration, so source and parameter changes deserve the same review discipline as application code.

Describe the generation boundary explicitly

The following JSON is a teaching record of expected inputs and output scope, not an Application schema or executed rendering request. No real repository, chart, tool version, or digest is invented. A real release record should replace the labels with authenticated identities. The expected resource set helps detect an accidental empty directory or a parameter that changes names and scope. It does not authorize pruning an unexpectedly missing resource; that needs a separate policy and ownership review.

json A synthetic rendering-input record

{"source":"parcel-config-lab","revision":"lab-r6","path":"apps/parcel","renderer":"reviewed-toolchain","values":"lab-values-c2","expected_kinds":["Deployment","Service"]}

The record is not sent to Argo CD and does not claim schema conformance. It describes review questions and uses labels rather than fake cryptographic identities.

Compare deterministic synthetic output

The complete local program creates a tiny resource-name list from declared inputs and stable ordering. It illustrates that a naming input changes output even when the source revision label is unchanged. It is not Helm, Kustomize, Kubernetes validation, or Argo CD manifest generation. Real renderers have richer semantics, supported options, and dependency behavior. Use their official local tools only in separately authorized appropriate practice; this course installs none and makes no platform execution claim.

python Model a rendering parameter’s effect

def rendered_names(prefix):
    return sorted([prefix + "-api", prefix + "-service"])
first = rendered_names("parcel")
second = rendered_names("parcel-preview")
print(first)
print(first == second)

Expected output

['parcel-api', 'parcel-service']
False

The function generates strings only. It does not produce Kubernetes manifests or determine whether names are valid for every resource kind.

Preserve generation evidence without secrets

When generation fails, record the exact source identity, path, renderer selection, relevant non-sensitive options, and bounded error. Check missing files, dependency availability, template syntax, and tool compatibility as distinct hypotheses. Values can contain sensitive material, so do not dump complete parameter or environment files into public logs. A successful retry can reflect a changed external input rather than a corrected source. Retain the explanation and compare the actual desired resource set before authorizing adoption, especially if output becomes empty or resource identity changes.

Common errors and fixes

Manifest generation failure is treated as a cluster apply failure.

Why it happens: The source-to-desired boundary was skipped in diagnosis.
How to fix it: Inspect source, renderer, inputs, and bounded generation error first.
Prevent it next time: Separate generation, comparison, sync, and health evidence.

A fixed Git revision is assumed to freeze every rendered byte.

Why it happens: Values, tools, dependencies, or nondeterminism were ignored.
How to fix it: Declare and control the relevant rendering inputs.
Prevent it next time: Record resolved identities and compare intended output.

A full values file is published as harmless diagnostics.

Why it happens: Rendering configuration was assumed non-sensitive.
How to fix it: Retain only necessary redacted fields and involve the secret owner if exposed.
Prevent it next time: Review values and generated output as potential disclosure channels.

Check your understanding

1. The Git revision is unchanged but a name-prefix parameter changes. Must the desired resource identities remain the same?

Show worked solution

No. The parameter can change generated names and therefore the resource set. Review the complete generation inputs and resulting ownership and prune implications. A source commit alone does not establish equal manifests.

2. Generation succeeds after a retry without a source change. What should the reviewer ask?