Automated release operator workflow

[didierofrivia]

This PR introduces an automated process for releasing the Kuadrant Operator. Similar to the previous one, one needs to provide the following inputs:

• gitRef: Select the branch/tag/commit where you want to cut a release from.
• kuadrantOperatorVersion: the Semantic Version of the desired release.
• authorinoOperatorVersion: Authorino Operator bundle version (X.Y.Z)
• limitadorOperatorVersion: Limitador Operator bundle version (X.Y.Z)
• dnsOperatorVersion: DNS Operator bundle version (X.Y.Z)
• wasmShimVersion: WASM Shim version (X.Y.Z)
• consolePluginVersion: ConsolePlugin version (X.Y.Z)
• olmChannel: This will set the OLM channels and default-channel.

But instead of tagging and creating the release automatically, instead it creates a PR in the same fashion that dictates the Manual Workflow

Verification steps
Sadly, it's not possible at the moment to fully check the workflow, since it needs to be merged to main and we might need to do some cleaning in our release branches before triggering it. But at the time being, we could use Act:

1. With act installed, you can run the following command

act -j auto-release --secret KUADRANT_DEV_PAT=[CHECK IN BITWARDEN] --input gitRef=8d8a86fbf25a2e6d6ad8aacf0d62423c3055eb83 --input kuadrantOperatorVersion=1.0.3-alpha1 --input authorinoOperatorVersion=0.16.0 --input limitadorOperatorVersion=0.12.1 --input dnsOperatorVersion=0.12.0 --input consolePluginVersion=0.0.19 --input wasmShimVersion=0.8.1 --input olmChannel=alpha --container-architecture linux/amd64

2. The output should be:

[Automated Release Operator/Release operator]   ✅  Success - Complete job
[Automated Release Operator/Release operator] 🏁  Job succeeded

3. At the step Prepare release, you should see

| Updating release.yaml with desired versions
| release.yaml file updated as follows:
| kuadrant-operator:
|   version: "1.0.3-alpha1"
| olm:
|   channels:
|     - "alpha"
|   default-channel: "alpha"
| dependencies:
|   authorino-operator: "0.16.0"
|   console-plugin: "0.0.19"
|   dns-operator: "0.12.0"
|   limitador-operator: "0.12.1"
|   wasm-shim: "0.8.1"

and at the end of the step, the following:

| INFO[0000] All validation tests have completed successfully

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Please upload report for BASE (release-process-enhancement@b0a573a). Learn more about missing BASE report.

Additional details and impacted files

@@                      Coverage Diff                       @@
##             release-process-enhancement    #1171   +/-   ##
==============================================================
  Coverage                               ?   83.67%           
==============================================================
  Files                                  ?       82           
  Lines                                  ?     7117           
  Branches                               ?        0           
==============================================================
  Hits                                   ?     5955           
  Misses                                 ?      933           
  Partials                               ?      229           

Flag	Coverage Δ
bare-k8s-integration	23.65% <ø> (?)
controllers-integration	74.19% <ø> (?)
envoygateway-integration	41.81% <ø> (?)
gatewayapi-integration	20.09% <ø> (?)
istio-integration	43.95% <ø> (?)
unit	19.08% <ø> (?)

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

Components	Coverage Δ
api/v1beta1 (u)	90.78% <0.00%> (?)
api/v1beta2 (u)	∅ <0.00%> (?)
pkg/common (u)	∅ <0.00%> (?)
pkg/istio (u)	62.06% <0.00%> (?)
pkg/log (u)	93.18% <0.00%> (?)
pkg/reconcilers (u)	24.50% <0.00%> (?)
pkg/rlptools (u)	∅ <0.00%> (?)
controllers (i)	86.70% <0.00%> (?)

[Boomatang]

Biggest concern is the creation of the pull request. It seems to be going to the wrong branch.

[Boomatang]

Here you are saying there is only ever one channels. If it is a final release, as in going to the stable channel, would it not also be going on the alpha channel?

[didierofrivia]

As I've seen in the OLM docs, they show, as you mentioned, that it's possible to release the same operator bundle under different channels...however, they also state that is up to the maintainer to chose the channels and more important the upgrade and channel promotions. So far we are not using their recommended channel naming other than stable, and from our part we've chosen to release anything else under alpha and in the past preview... I think either we still keep doing so, a simplistic way, or we will need to discuss how we will approach the upgrade and channel promotion for our operator. Maybe another question would be: Are we expecting to find an operator bundle that is released under alpha channel also be in the stable one and vice-versa? What would be the expectations of the OLM Subscriptions to those channels?

[Boomatang]

Looking at the sed command raises and interesting question. Should we be doing validation on the user input to ensure they are valid semver?

[Boomatang]

This related to this, would also affect the manual approach.

The PR is opened with the changes from the prepare-release, and some thing is missing from the release, lets say missing commit from main. That missing commit can be cherry picked to the branch which is the base targeting the release branch.

What should happen in that case? I am assuming the history of the base branch should be reordered to have the cherry picked commit before the release commit. The same would go for if during the review a wrong version is noticed. Would that be adding in a new commit or the release commit edited?

[didierofrivia]

Basically any change in the history of the branch could be done in the PR, manually.

[Boomatang]

That I understand. The question would be should the history be reordered to ensure the Prepare release commit is the head of the branch?

[Boomatang]

It is looking good, could I ask you to tidy up the commit history and then I will approve it.

[Boomatang]

Looks good to me