Feature Overview

When parsing app source, imgae updater checks both spec.source and spec.sources fields. With the addition of source hydration feature in Argo CD, the source info can also be specified via spec.sourceHydrator field. Image updater currently (as of v1.0.2) does not recognize source specification with hydrator.

This feature aims to support source hydration in image updater future releases, to allow users to leverage source hydration with image updating.

Goals

GitOps and Argo CD users who adopts source hydration in their workflow will not be able to use image updater unless this feature is implemented future releases of image updater. 

After this feature is completed, users will have the flexibility to use image updater for apps configured with source hydration.

Requirements

Use Cases

Add support in Image Updater (CRD-based configuration) to recognize and use spec.sourceHydrator.drySource as a valid application source.

Out of scope

• support source hydration in legacy annotation-based impl
• use hydrated source as write-back target

Dependencies

< Link or at least explain any known dependencies. >

Background, and strategic fit

Community issue: https://github.com/argoproj-labs/argocd-image-updater/issues/1403 

Argo CD source hydration: https://argo-cd.readthedocs.io/en/stable/user-guide/source-hydrator/

Argo CD Image Updater latest doc: https://argocd-image-updater.readthedocs.io/ 

Assumptions

< Are there assumptions being made regarding prerequisites and dependencies?>
< Are there assumptions about hardware, software or people resources?>

Customer Considerations

align this feature with the overall support of source hydration in OpenShift GitOps.

Documentation/QE Considerations

• this feature will be documented via image updater community docs https://argocd-image-updater.readthedocs.io/
• unit tests, e2e tests and sample apps will be created

< What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >
< Does this feature have a doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>
< Are there assumptions being made regarding prerequisites and dependencies?>
< Are there assumptions about hardware, software or people resources?>

Impact

< If the feature is ordered with other work, state the impact of this feature on the other work>

Related Architecture/Technical Documents

<links>

Definition of Ready

• The objectives of the feature are clearly defined and aligned with the business strategy.
• All feature requirements have been clearly defined by Product Owners.
• The feature has been broken down into epics.
• The feature has been stack ranked.
• Definition of the business outcome is in the Outcome Jira (which must have a parent Jira).