Hi Gyula, Agree, we should include the bundle file and let community inspect them in the staging repo. In addition, people can do a few things to test the bundle files. 1. Run CI test suits (https://github.com/tedhtchang/olm#run-ci-test-suits-before-creating-pr) with the bundle files directly. 2. Deploy operator with OLM (requires the bundle image in a registry) 3. Test operators upgrade from the previous version with OLM(requires both bundle and catalog image in a registry)
For 2 and 3, it’s better to build a bundle and catalog images as part of the staging. For example, during the next release(1.3.0-rc1), temporally push the 2 images to ghcr.io/apache/flink-kubernetes-operator-bundle:1.3.0-rc1 and ghcr.io/apache/flink-kubernetes-opeator-catalog:1.3.0-rc1. Then, community can test 2. and 3. easily with the following commands: # Deploy the catalog src in default ns cat <<EOF | kubectl apply -f - apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: olm-flink-operator-catalog namespace: default spec: sourceType: grpc image: ghcr.io/apache/flink-kubernetes-opeator-catalog:1.3.0-rc1 EOF # Deploy operator from the catalog Cat <<EOF | kubectl apply -f - apiVersion: operators.coreos.com/v1alpha2 kind: OperatorGroup metadata: name: default-og namespace: default spec: targetNamespaces: - default --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: flink-kubernetes-operator namespace: default spec: channel: alpha name: flink-kubernetes-operator source: olm-flink-operator-catalog sourceNamespace: default # For testing upgrade from previous version # installPlanApproval: Automatic # Manual # startingCSV: flink-kubernetes-operator.v1.2.0 EOF
