akuity
Stage healthchecks should assert all associated Application specs are consistent with Stage state
If an Argo CD Application has a git repo as its source and a corresponding Environment subscribes to that repo, we know exactly what commit the Application should be synced to for a given Environment state. We account for that when assessing Application health and sync state (as part of the comprehensive assessment of overall Environment health).
~~If an Application doesn't use a git repo (that we subscribe to) as the source, our assessment of health is less comprehensive. We can improve this...~~
~~Consider, for instance, the possibility that an Environment subscribes to an image or chart repository and updates kustomize.images or helm.parameters of an Application accordingly. Health checks can be enhanced to check that those attributes are set as expected to assert that an Application is in-sync with the desired state.~~
Kargo promotion mechanisms are also capable of modifying Argo CD Application specs with changes to targetRevision, Kustomize-specific parameters, or Helm-specific parameters. Environment healthchecks do not currently assert that every associated Application resource is defined in a manner consistent with the Environment's current state. We could and should address that.
A great idea from @moensch in #935:
In theory, Kargo could query .status.summary.images of the Application resource