kie-tools#2751: Remove references to Quarkus and Kogito versions; Automatic change of platform images based on env context

[ricardozanini]

Fix #2751

In this PR:

• Removal of hardcoded Quarkus and Kogito versions from the operator
• Add Kogito and Quarkus versions to all images in the platform
• When adding a new extension, use the Kogito and Quarkus versions from the platform
• Operator won't pass versions from the platform to the builder anymore; hence the builder will fetch the extension based on the platform version. It's still possible to pass the version if needed by users
• Removal of every docker.io mention in the code that's not generated
• Added a script to update the controllers_cfg.yaml and SonataflowBuilder.dockerfile files based on the env context from dependant images

[wmedvede]

@ricardozanini If I don't remember wrong, this bump-version.sh script is executed as part of the automations executed during the release process, to adjust the image names to the version to be released etc.

If the image names setting is removed from this script to the make invoked python update_controllers_cfg.py, are you sure this is also executed as part of the automations?

Not saying this is bad, just double checking

[ricardozanini]

@wmedvede I've removed it here because we are bumping the new Python script.

This script runs during the build process, guaranteeing our versioning and image values. So, if the automation uses pnpm build:prod and follows the patterns we established in this repo, we should not have any problems.

If we would, I'd blame @tiagobento 🤣

[wmedvede]

OK, so the idea is that we remove the version from here, and at the time of executing run_quarkus_mvn_add_extension (bla, bla), the extension number will be taken from the kogito-version or the quarkus-version that corresponds to current product version (just built) accordingly, right?

And the mechanism works on the basis that, to have the version auto-filling, extensions must mandatory belong to gropups io.quarkus, org.kie, or "kogito".

This leaves out the possibility of configuring an extension that don't belong to any of these groups right? (at least in controllers_cfg.yaml)

Also, one thing that comes to my mind. With this new mechanism (in a given installation) it's not possible to configure the controllers config file to point to a different version, right?

Thinking about situations where you want to quickly do something like this:

1. something is not good
2. I quickly configure the controllers config ConfigMap with a different version ej 9.101.xxxxx, instead of 9.102.xxxxx
3. restart the operator pod, And I can quickly see if things works with the previous version to test, etc.

[wmedvede]

Maybe we can just the data structure/processing as is, and keep the version field.
However, we don't set it anymore. So, if not set, the automatic mechanism will be applied.
But we keep the trapdoor.

[ricardozanini]

@wmedvede I'd rather remove for good the possibility of adding the version since the platform will provide it. If we need to add the version to any other future library to the controller_cfg, we can then create a new data structure for it. But even in these cases, I'd rather have dependency control within the platform.

This hack you mentioned crossed my mind (change the version to check if the workaround works). In this case, one can use the build ARGS QUARKUS_EXTENSIONS directly to the SonataFlowBuild.

[ricardozanini]

I'll rebase this PR after #2818

[jomarko]

FYI #2813 was merged, probably causes conflicts to this PR.

[ricardozanini]

@wmedvede @rgdoliveira can you please review?