Story

As a developer on the Argo CD Image Updater project, I want to refactor the existing webhook server to use the sigs.ks.io/controller-runtime/pkg/webhook library so that it integrates cleanly with the main controller manager, leverages standard Kubernetes patterns, and simplifies maintenance.

Background and Approach

Background: The current webhook server in

pkg/webhook/server.go is a custom implementation built using the standard net/http library. While functional, it operates independently of the main controller manager. The controller-runtime project, which we use for our main operator logic, provides a mature and standardized library for building admission webhooks. Adopting this library for our registry event receiver will align our entire project with a single, consistent architectural pattern, making it more robust and easier to manage.

Approach: This story involves replacing the custom http.Server implementation with the components provided by controller-runtime.

1. Define a Webhook Handler: Create a new struct that implements the webhook.Handler interface from controller-runtime. This struct will contain the logic to decode, validate, and process incoming registry events.

1. Move Logic: The core logic from the existing handleWebhook and processWebhookEvent functions in server.go will be moved into the new handler's Handle method.

1. Register the Webhook: In cmd/run.go, where the main controller Manager is configured, register the new webhook handler with the manager's webhook server. This is typically done with a call like mgr.GetWebhookServer().Register("/webhook", &webhook.Admission{Handler: &myRegistryEventHandler{){}}}.

1. Remove Old Code: The custom server implementation in pkg/webhook/server.go and the separate startup logic in cmd/webhook.go will be removed, as the controller manager will now handle the server's lifecycle.

Out of Scope

• This story is focused on refactoring the server implementation to use controller-runtime. It does not include the major refactoring of the webhook's internal logic to make it fully CRD-aware (which is a separate story, GITOPS-7336).

• This story does not cover the validating admission webhook for preventing CRD conflicts.

Dependencies

• This story is part of the larger effort to align the entire project with controller-runtime.

Acceptance Criteria

1. The custom

http.Server in pkg/webhook/server.go is removed and replaced with a controller-runtime compatible handler.

1. The standalone webhook command and its startup logic in cmd/webhook.go are removed.

1. The new webhook handler is registered and started by the main controller Manager in cmd/run.go.

1. The server correctly exposes a /webhook endpoint.

1. Sending a valid registry event payload (e.g., from Docker Hub) to the endpoint correctly triggers the existing processWebhookEvent logic.

1. The go.mod file is updated to include any new dependencies required by the controller-runtime/pkg/webhook package.

Definition of Done

• Code Complete:
  • All code has been written, reviewed, and approved.
• Tested:
  • Unit tests have been written and passed.
  • Ensure code coverage is not reduced with the changes.
  • Integration tests have been automated.
  • System tests have been conducted, and all critical bugs have been fixed.
  • Tested and merged on OpenShift either upstream or downstream on a local build.
• Documentation:
  • User documentation or release notes have been written (if applicable).
• Build:
  • Code has been successfully built and integrated into the main repository / project.
  • Midstream changes (if applicable) are done, reviewed, approved and merged.
• 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.