Fix bundle build workflow

[adam-cattermole]

Porting of the changes from https://github.com/Kuadrant/authorino-operator/tree/v0.9.0 to fix the release workflow and manifests building.

[guicassolato]

Let's also default to stable channel in the bundle annotations file?

authorino-operator/bundle/metadata/annotations.yaml

Line 7 in aee73cf

operators.operatorframework.io.bundle.channels.v1: alpha

[adam-cattermole]

Sure latest commit added where I ran make manifests bundle CHANNELS=stable DEFAULT_CHANNEL=stable

[adam-cattermole]

Actually, maybe I should set CHANNELS?=stable by default in the Makefile, the default with --overwrite behaviour from operator-sdk is to set it to alpha when not defined

[adam-cattermole]

Oh maybe the same should be true for DEFAULT_CHANNEL - verify fails as it does not set either of these by default

[codecov-commenter]

Codecov Report

Merging #153 (f5ff784) into main (aee73cf) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #153   +/-   ##
=======================================
  Coverage   62.85%   62.85%           
=======================================
  Files           1        1           
  Lines         735      735           
=======================================
  Hits          462      462           
  Misses        222      222           
  Partials       51       51           

Flag	Coverage Δ
unit	62.85% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[guicassolato]

Approving this for now but hoping anytime soon we get more insights on the stable vs alpha default channel name debate.

[guicassolato]

I've been banging my head with this change (discussed offline)...

Starting at v0.9.0, we define one OLM channel called stable. It used to be alpha in previous versions and, until this PR gets merged, it still is in the main branch, out of which we build the bundle and catalog :latest images.

On one hand, having the stable channel for the released versions as well as in main makes things easy and straightforward. It leaves alphacompletely in the past and ensures a more seamless UX between released and latest versions.

On the other hand, I wonder if semantically we might be sending the wrong message that latest == stable, and therefore if stable should be reserved to released versions of the operator only.

To exemplify, consider the following. Say you have:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: operatorhubio-catalog
  namespace: authorino-operator
spec:
  sourceType: grpc
  image: quay.io/kuadrant/authorino-operator-catalog:v0.9.0
  displayName: Authorino Operator
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: authorino-operator
spec:
  channel: stable
  installPlanApproval: Automatic
  name: authorino-operator
  source: operatorhubio-catalog
  sourceNamespace: authorino-operator

And then, in the CatalogSource, you change to:

  image: quay.io/kuadrant/authorino-operator-catalog:latest

What would you expect to happen? With stable in the released version and alpha in main/latest, the “upgrade” from v0.9.0 to latest would fail. Whereas, with stable/stable, latest is rollout out without hiccups.

What’s the safest behaviour to enforce here? Would failing the upgrade from a released version to latest be a valid way to tell users that latest is not to be considered stable? Or, as a user, would you prefer to keep it simple with one single channel name and make the upgrade work out of the box?

[adam-cattermole]

I have changed the behaviour to default to alpha on the main branch. When we provide the DEFAULT_CHANNEL and CHANNELS as part of the release workflow the bundle.Dockerfile and bundle annotations will be updated to the correct channels.

If we want to build catalogs from main branch and test the upgrade from a previously released bundle version we need to specify stable for the channels above when building the bundle from main.