-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix bundle build workflow #153
Fix bundle build workflow #153
Conversation
(cherry picked from commit 35ef655)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's also default to stable
channel in the bundle annotations file?
operators.operatorframework.io.bundle.channels.v1: alpha |
Sure latest commit added where I ran |
Actually, maybe I should set |
Oh maybe the same should be true for |
b1a13fa
to
ce1fd94
Compare
Codecov Report
@@ Coverage Diff @@
## main #153 +/- ##
=======================================
Coverage 62.85% 62.85%
=======================================
Files 1 1
Lines 735 735
=======================================
Hits 462 462
Misses 222 222
Partials 51 51
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving this for now but hoping anytime soon we get more insights on the stable
vs alpha
default channel name debate.
Makefile
Outdated
@@ -38,15 +38,13 @@ BUNDLE_IMG ?= $(IMAGE_TAG_BASE)-bundle:$(IMAGE_TAG) | |||
|
|||
# CHANNELS define the bundle channels used in the bundle. | |||
# Add a new line here if you would like to change its default config. (E.g CHANNELS = "candidate,fast,stable") | |||
ifneq ($(origin CHANNELS), undefined) | |||
CHANNELS ?= stable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 alpha
completely 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?
ce1fd94
to
39ca1d5
Compare
39ca1d5
to
f5ff784
Compare
I have changed the behaviour to default to If we want to build catalogs from main branch and test the upgrade from a previously released bundle version we need to specify |
Porting of the changes from https://github.com/Kuadrant/authorino-operator/tree/v0.9.0 to fix the release workflow and manifests building.