Epic Goal

• Multi-source apps in general can work well with image updater. But when a multi-source app contains a kustomize source, a helm source, and a values source, image updater can get confused which source is the primary source used for writing updates. In such case, image updater should be enhanced to check the write-back configuration, in addition to app spec and status, in order to identify the correct primary source.

Why is this important?

• Users may configure their apps to contain both helm and kustomize, and configure the write-back to a particular source. This use case should be supported.

Scenarios

1. create a multi-source app containing helm source, kustomize source, and values source
2. configure the write-back target to be the helm values file 
3. verify that the helm source should be identified as the primary source, despite the first source being kustomize source
4. also verify that a non-existing, or empty values file should still work, and image updater should create or populate the content with update params
5. Note: if git write-back is configured without a target, image updater by default will write to the default target .argocd-source-<app-name>. This case is not affected by this issue.
6. This issue is for the current master branch only. The legacy impl in master-annotation-based branch already works correctly.

Other Considerations

• multi-source applicaitons, kustomize applications, helm applications are supported
• unit tests to validate the above merged
• doc update merged 

Definition of Ready

• The epic has been broken down into stories. Stories have been scoped.
• The epic has been stack ranked.

Definition of Done

• Code Complete:
  • All code has been written, reviewed, and approved.
• Tested:
  • Unit tests have been written and passed.
  • Integration tests have been completed.
  • System tests have been conducted, and all critical bugs have been fixed.
  • Tested on OpenShift either upstream or downstream on a local build
• Documentation:
  • User documentation or release notes have been written.
• Build:
  • Code has been successfully built and integrated into the main repository / project
• Review:
  • Code has been peer-reviewed and meets coding standards.
  • All acceptance criteria defined in the user story have been met.
  • Tested by reviewer on OpenShift
• Deployment:
  • The feature has been deployed on OpenShift cluster for testing
• Acceptance:
  • Product Manager or stakeholder has reviewed and accepted the work.