Do multiple git generators with the same branch revision always resolve the same commit?

[fabiobaiao]

Is it guaranteed that all git generators inside a matrix/merge generator with the same revision (e.g. HEAD) will resolve the same commit? Or is it possible (however unlikely) that while the applicationset controller is processing an ApplicationSet it resolves one commit for a git generator and then a newer commit on another git generator (for example, perhaps due to the repo-server cache expiring in-between: https://argo-cd.readthedocs.io/en/latest/operator-manual/applicationset/Generators-Git/#git-polling-interval)

Example: https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Generators-Matrix/#overriding-parameters-from-one-child-generator-in-another-child-generator

Edit: Btw, what about the same branch revision on multiple sources of an application?

[MILLERMARRU]

Not guaranteed. Each Git generator fetches independently from the repo-server cache, and the cache has a TTL (default 3 minutes for polling). If a new commit is pushed between when the first generator resolves HEAD and when the second generator resolves HEAD, they can land on different commits.

In practice this race is rare for typical commit frequencies, but it is a real possibility — especially in high-velocity repos or when the cache expires mid-evaluation.

For the multi-source application question: same answer — each source is resolved independently, so HEAD on two sources of one application can theoretically resolve to different commits during the same sync cycle.

How to get strict consistency:

1. Pin to a commit SHA instead of HEAD. This is the only guarantee that all generators/sources see the same state:

   revision: "abc123def456"

   You would update the SHA via a separate pipeline step (e.g., a PR that bumps the revision after CI passes).

2. Use a single Git generator that produces all the parameters you need, rather than multiple generators in a matrix. If one generator fetches once and produces all the values, there is no second fetch.

3. Use a tag instead of a branch. Tags are immutable — once created, HEAD of a tag always points to the same commit. A branch can receive new commits between two fetches.

4. Accept the eventual consistency. If your generators produce idempotent applications (same inputs always produce same output), a one-commit drift between generators will self-correct on the next sync cycle without user impact.

The ApplicationSet controller does not hold a lock across generator evaluations, so there is no built-in mechanism to make a multi-generator evaluation atomic against concurrent pushes.