Release process/workflow

[Boomatang]

This PR targets the uses of a release.toml file for releases.

There are a number of changes that have being done in the hope to simplify future work.

The first main change is the adding of a release.toml file for the release. Below is a sample of what this file will look like. The file will be saved at the root of the project.

[kuadrant]
channels = ["alpha"]
default_channel = "alpha"
release = "1.0.1"

[dependencies]
Authorino_bundle = "0.16.0"
Console_plugin = "0.0.14"
DNS_bundle = "0.12.0"
Limitador_bundle = "0.12.1"
Wasm_shim = "0.8.1"

The next major change is moving the moving the release code out of the Makefiles and into self contained scripts. Every thing from the tools required to validation. This is an attempt to allow the make the steps required to do a release simpler.

Validation

To validation that the process is still working as expected.

• check out this branch
• create a worktree for a past release. This sha was before cutting the release for v1.0.1

git worktree add /tmp/review 14d99004ab8dfda4bd4f8e50191da28d8bc85aa9

• Create the release.toml file in the root of the project.

echo '[kuadrant]
channels = ["alpha"]
default_channel = "alpha"
release = "1.0.1"

[dependencies]
Authorino_bundle = "0.16.0"
Console_plugin = "0.0.14"
DNS_bundle = "0.12.0"
Limitador_bundle = "0.12.1"
Wasm_shim = "0.8.1"' > /tmp/review/release.toml

• Run the release script. NOTE: this will download any tools required that are missing from your path

ROOT=/tmp/review make perpare-release

• compare the resulting changes with the commit that was created during the v1.0.1 release.

git -C /tmp/review diff 1e417b087bd96a5a1f5fc0c3e53e2237b324c1f8

The expected changes are as follows

• The createdAT timestamp being different
• The make/release.mk file being missing.

[eguzki]

Before jumpling to the review of the implementation:

• The location that the tools are being installed to has also being changed to ~/.local/bin -> this can break interoperability with other repos that are using same tools (yq, helm, operator-sdk, kustomize) and require specific version.
• I do not see as an issue the Golang dependency for installing tools. From the perspective of somebody releasing, it would be interacting with GH workflows, so no need to have golang installed. From the perspective of engineering, we all have. And to be honest, golang provides very nice/easy (not simple) mechanism to install tools locally.

What are your thoughts?

[Boomatang]

After the call today the implementation is changing and some of points to address your comments are not as valid.

The breaking of interoperability with other repos. So what if it does. Prior to the call today, these scripts were being designed to run in GitHub workflows. There should be no other repos using the tools. The argument over requiring specific version for the different repos, ya I can see that, but that problem also exists today. I don't add the project bin to my PATH every time I enter the project. So if I call any of those tools out side the make targets it is highly likely the version don't match. Even if the I was to use one in the project bin there is no guarantee that version would be the correct version. This has happened to me more than once were a version of a tool was updated and the only way I found out was by a failing build. Think we high to much of the complicity around tooling in the make targets. I do like the idea of nix for the management of tools, but I think it better to warn if a version we don't expect is being used.

On the Golang dependency, that is a hard one. Someone doing a release that is all in the GitHub workflows, they should not need it locally. We can agree on that. When I don't think we will agree is on the perspective of engineering. You say we all have, but that is not true. Last week I found my self using a machine that didn't have Golang install. In fairness, I was only wanting to explore the operator running, and do much edits. But I couldn't run make local-setup as it requires Golang even tho it builds the operator in container files. That machine still does not have Golang installed, and I still have not explored what I was going to look at. If there was no way to build the operator but only using go build locally, or all the dev tools could be installed using Golang, then ya I would have a lesser issue with it. We know the arguments between easy and simple, and I don't want to go there.