Epic Goal

To refactor the existing webhook receiver for container registry events (Docker, GHCR, Harbor) so that it integrates with the new controller-runtime and ImageUpdater CRD architecture. The goal is to trigger targeted reconciliations of the appropriate ImageUpdater CRs in response to a new image push event.

Why is this important?

The current webhook receiver was designed for the legacy, annotation-based model where it would list all Applications to find a match. The new CRD model, however, holds all the image-watching configuration within ImageUpdater CRs.

This refactoring is essential to bridge the gap between incoming registry events and the new CRD-driven logic. It will transform the webhook from a broad, annotation-scanning tool into a precise, event-driven trigger for the controller, resulting in a much more efficient and responsive system for users who want immediate updates when a new image is pushed. Without this, the webhook functionality will not work with the new operator.

Scenarios

• A user has an ImageUpdater CR configured to watch my-image:v1.0.0. A CI/CD pipeline pushes a new tag, my-image:v1.1.0, to the container registry. The registry sends a webhook event to the argocd-image-updater endpoint. The webhook server correctly identifies which ImageUpdater CR is watching my-image and triggers an immediate reconciliation for that CR, which then updates the application.

• A webhook event is received for an image that is not being watched by any ImageUpdater CR. The server correctly identifies that no action is needed and logs a debug message.

Other Considerations

• Out of Scope: This epic is focused on refactoring the triggering mechanism of the webhook. The core logic for handling Docker, GHCR, and Harbor events, which already exists, should be reused. This does not cover the implementation of the validating admission webhook, which is a separate feature.

• Dependencies: This work depends on the core reconciliation logic being in place. The webhook needs a stable Reconcile function to trigger.

• Previous Works: A fully functional webhook receiver for the annotation-based model exists. This epic will adapt that logic to the new CRD model.

• Unanswered Questions: How will the webhook server efficiently find the correct ImageUpdater CR to reconcile? (e.g., Will it list and filter all CRs, or will it use an index on the images.imageName field for faster lookups?)

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.