The webhook server has a hardcoded map of apiVersions for a few resources
here.
Version v1beta1 of image.toolkit.fluxcd.io (including ImageRepository) has been
released in June of last year. But this hardcoded version has not been updated
since.
Because of this, sending a webhook to a Receiver with a target resource of kind
ImageRepository without an explicit apiVersion, reverts it to apiVersion
image.toolkit.fluxcd.io/v1alpha1. This breaks its reconciliation forever if any
incompatible configuration is used (e.g. accessFrom).
A solution is to bump this hardcoded version to the current latest. This
results in a breaking change for notification-controller and is a shortsighted
solution IMHO.
Instead, could the apiVersion be left untouched during the patch by matching
resources only based on the provided metadata (kind, name and namespace)?
The webhook server has a hardcoded map of
apiVersions for a few resourceshere.
Version
v1beta1ofimage.toolkit.fluxcd.io(includingImageRepository) has beenreleased in June of last year. But this hardcoded version has not been updated
since.
Because of this, sending a webhook to a Receiver with a target resource of kind
ImageRepositorywithout an explicitapiVersion, reverts it toapiVersionimage.toolkit.fluxcd.io/v1alpha1. This breaks its reconciliation forever if anyincompatible configuration is used (e.g.
accessFrom).A solution is to bump this hardcoded version to the current latest. This
results in a breaking change for notification-controller and is a shortsighted
solution IMHO.
Instead, could the
apiVersionbe left untouched during the patch by matchingresources only based on the provided metadata (
kind,nameandnamespace)?