Release Process Improvements

[maleck13]

What

While we have a release process and it is reasonably light weight. I think there are some improvements we can make that will improve the quality of life of the person coordinating the release and make it a more easily understood and stable process.

Possible flow outline:

Key goal here is to remove the need for inputting versions of components over and over again.

Minor

1. create release-v1.x branch with a release only file that contains the versions for this release. We somewhat have this in the release.mk file but this is generated by the inputs rather than just committing it directly. If we want to keep the release.mk file possibly it could be re-used or import the new file?

AUTHORINO_OPERATOR_VERSION=0.16.0
LIMITADOR_OPERATOR_VERSION=0.12.1
DNS_OPERATOR_VERSION=0.12.0
WASM_SHIM_VERSION=0.8.1
CONSOLEPLUGIN=0.0.18
CHANNELS=stable
KUADRANT_VERSION=1.1.0 # should also work with -rc1 for example

Check this in and push it to the remote.
2) Trigger GH workflow that uses the release-v1.x branch (this should be the only needed input)

• generate the bundle based on the versions provided
• update the catalog under config/deploy/olm to point to the catalog image
• generate any needed helm bits
• commit the changes
• create the release tag and release in GH

3. once the release tag is created it should auto trigger a build of the images. This should also use this file to generate the image urls and tags. It should be possible to re-run this workflow if needed. Again the only input should be the release branch to use to generate the images.

Patch
For a patch release it should just be the same other than creating a release-v1.x branch. New code changes should be added to the needed release branch (ideally from cherry-picks from main), updating any needed version bumps and re-running the release workflow from the release-v1.x branch.

In the workflow the first step should be to output the commit hash, the branch name and the versions that will be used in this release.

** note on the release.mk file **
At this point lets say if the file doesn't exist, then fall back to latest.

• Define the new release doc
• Implement what is required to bring it to reality

[maleck13]

@eguzki @Boomatang

[Boomatang]

I have done two things.

1. Created a feature branch in kuadrant/kuadrant-operator to track changes that are wanted to be introduced. https://github.com/Kuadrant/kuadrant-operator/tree/release-process-enhancement
2. I opened a draft PR against the feature branch that has the initial changes I want to make to the RELEASE.md. UPDATE: Release Document #1133. It would be good to get a initial once over of the changes.

[maleck13]

Based on our discussion we will move look to move to a process that flows as below:

Locally:
  - create kuadrant-vX.Y branch (if doesn't already exist) and push to remote
  - create kuadrant-vX.Y.Z-rc(n) branch (with updated versions in release.toml)
  - Run the prepare release workflow using the kuadrant-vX.Y.0-rc(n)  branch (that would setup the helm and bundle stuff) locally (it will use the release.toml file)
Remote:
  - Open PR against kuadrant-vX.Y branch kuadrant-vX.Y.Z-rc(n) branch (that would trigger tests)
  -  Upgrade workflows will trigger on these branches
  -  Get PR approved (so bundle and helm can be seen and version)
  - Merge PR
  - Run Release Workflow that would create the GH release and final tags etc