It seems like controller-runtime (CR) accepts ['debug', 'info', 'error'] for the zap-log-level flag, but in this project, we also accept 'panic'. Our ambition is to be a "drop-in replacement for controller-runtime zap package", so this should not differ.
See https://github.com/kubernetes-sigs/controller-runtime/blob/ffa8c5001e6afb386877ecacdbe6975245c5ca2c/pkg/log/zap/flags.go#L31-L41 for details.
I tried to fix this "the weasel way" (removing 'panic' from https://github.com/statnett/controller-runtime-viper/blob/main/pkg/zap/zap.go#L127-L132), but that broke tests. The main issue seems to be that we cannot distinguish the decoding of fields of the same type.
It seems like controller-runtime (CR) accepts ['debug', 'info', 'error'] for the
zap-log-levelflag, but in this project, we also accept 'panic'. Our ambition is to be a "drop-in replacement for controller-runtime zap package", so this should not differ.See https://github.com/kubernetes-sigs/controller-runtime/blob/ffa8c5001e6afb386877ecacdbe6975245c5ca2c/pkg/log/zap/flags.go#L31-L41 for details.
I tried to fix this "the weasel way" (removing 'panic' from https://github.com/statnett/controller-runtime-viper/blob/main/pkg/zap/zap.go#L127-L132), but that broke tests. The main issue seems to be that we cannot distinguish the decoding of fields of the same type.