refactor NewDefaultUnpacker due to growing parameter list
https://github.com/operator-framework/rukpak/blob/3b832db489499105211cda18f2217aad89e2bb8f/internal/source/unpacker.go#L103
// NewDefaultUnpacker returns a new composite Source that unpacks bundles using
// a default source mapping with built-in implementations of all of the supported
// source types.
//
// TODO: refactor NewDefaultUnpacker due to growing parameter list
func NewDefaultUnpacker(mgr ctrl.Manager, namespace, provisionerName, unpackImage string, baseUploadManagerURL string, rootCAs *x509.CertPool) (Unpacker, error) {
cfg := mgr.GetConfig()
kubeClient, err := kubernetes.NewForConfig(cfg)
if err != nil {
return nil, err
}
httpTransport := http.DefaultTransport.(*http.Transport).Clone()
if httpTransport.TLSClientConfig == nil {
httpTransport.TLSClientConfig = &tls.Config{}
}
httpTransport.TLSClientConfig.RootCAs = rootCAs
return NewUnpacker(map[rukpakv1alpha1.SourceType]Unpacker{
rukpakv1alpha1.SourceTypeImage: &Image{
Client: mgr.GetClient(),
It isn't immediately clear what the solution is. The parameters in this field are required for the default unpacker, the number of required parameters will probably grow, and other unpackers will be built on top of this unpacker.
Moving these parameters to an options pattern will force us to evaluate the validity of the structure at runtime, creating additional work and error handling.
I can't propose a solution now, but I am removing the good first issue label from the issue until we've settled on a design.
This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.