[Epic] : Kuadrant Upgrades

[maleck13]

This work is not directly impacted by the work in #1122 but is related to it

Note while we call out workflows, these actions should be reproducable locally. The workflows should just take the actions a developer would (IE provide inputs and install CLI for example)

What

Once we have a release candidate or new release of kuadrant, we should be able to trigger testing the upgrade from the previous version to the new version works for the installation tools we support.

Ideally we would install the previous version into a cluster such as a kind cluster (although it would be ideal to be able to target a cluster also ) and then trigger the upgrade to the new version. This workflow could take inputs of previous and next version and then test the upgrade from the previous all the way to the next version.

I can imagine having 2 workflows.

one for installing kudarant onto a kind cluster at a specific version or if possible a target cluster via the install method (IE OLM) at a specified version. Wondering if we had a drop down of (kind | ocp) and if OCP it expects a kubeconfig from a GH action secret with well known secret names?

and another for performing the actual upgrade that called the first one to setup the cluster this would be useful in general as then installing a new version on to an eng OCP for example would be a simple automated process.

For doing an OLM based install we can use the follow guide to setup some useful files
https://docs.kuadrant.io/dev/install-olm/

For doing an OLM upgrade, I use the operator-sdk run bundle-upgrade <target bundle> command. This seemed to work well and had nice output. So if we have a new bundle, we should be able to install the previous version from the previous catalog image and then trigger an upgrade using the bundle upgrade command. This way we can allow the upstream catalogs to handle the meta data and we can just ensure the upgrade will work