New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Filtering for incoming webhooks #491
Comments
I'm not sure I'm following what you're requesting. Would you mind describing the envisioned API changes and/or workflow you're aiming at, please? |
Currently we have a single receiver to consume notifications from our GCR/GAR. In this receiver |
I will go even deep. The primary concern isn't just that all images are annotated for reconciliation. The core issue is the reconciliation process itself. I have thousands of images, and with each new webhook received, there's a scan of all image tags in Harbor. This results in significant resource consumption in Harbor instance. |
Each provider has a unique payload schema, we'll need to get all those schemas as dependencies (does al of them have Go SDKs?). After that we'll need to write a custom parser for each one, to be able to extract some string that may or may not match the Flux resource name listed under |
A more generic approach similar to the support for filtering on Events for GitHub, etc.
For example GCR/GAR sends a pretty simple, but also useful payload:
Ref: https://cloud.google.com/artifact-registry/docs/configure-notifications#examples
It would be nice to be able to map the digest to a ImageRepository to notify (either automatically or explicitly configured). This could potentially reduce the load within and caused by Flux drastically.
The current alternative (to reduce the load) is to configure separate incoming webhooks on both GCR/GAR's and Flux' side. Which is rather cumbersome.
The text was updated successfully, but these errors were encountered: