text below created with the help of AI

Epic Goal

• Enable ImageUpdater to work seamlessly with ApplicationSets by allowing a single ImageUpdater CR to target multiple Applications and read image update configuration from existing legacy annotations (argocd-image-updater.argoproj.io/*) on those Applications.

Why is this important?

• 1. Customer Pain Point: Users with 300+ ApplicationSets generating 1000+ Applications cannot effectively use the CRD-based ImageUpdater. The current approach requires either:
  •  
  • One applicationRef entry per Application in a single CR (1000+ entries - doesn't scale)
  1. Migration Blocker: Users migrating from annotation-based 0.x to CRD-based 1.x cannot leverage their existing ApplicationSet templates that already include argocd-image-updater.argoproj.io/* annotations.
  2. Community Demand: This is a highly requested feature with multiple upvotes.
  3. DRY Principle: Without this feature, users must duplicate configuration - once in ApplicationSet templates (for Application generation) and again in ImageUpdater CRs.
  4. Operational Overhead: Managing thousands of CRs or maintaining huge CR files with thousands of entries creates significant operational burden and risk of configuration drift.

Scenarios

Scenario 1: Large-scale ApplicationSet Migration

As a platform engineer with 300 ApplicationSets generating 1000 Applications I want to create one ImageUpdater CR per ApplicationSet that reads configuration from Application annotations So that I can migrate to CRD-based ImageUpdater without rewriting my ApplicationSet templates or managing 1000 CRs

Scenario 2: Existing Annotation-based Configuration

As a user with existing ApplicationSets that template legacy argocd-image-updater.argoproj.io/* annotations I want to use these existing annotations with the new CRD-based controller So that I don't need to modify my ApplicationSet templates or Application configurations

Scenario 3: Mixed Configuration

As a userI want to use label selectors to target Applications from a specific ApplicationSet So that one ImageUpdater CR handles all Applications with matching labels, regardless of their individual names

Scenario 4: Gradual Migration Path

As a user migrating from annotation-based (0.x) to CRD-based (1.x) ImageUpdater I want to keep my existing Application annotations and just add an ImageUpdater CR with readFromApplicationAnnotations: true So that I can migrate incrementally without disrupting existing workflows

Other Considerations

• https://github.com/argoproj-labs/argocd-image-updater/issues/1382
• https://github.com/argoproj-labs/argocd-image-updater/discussions/1350

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.