From e177d656808bbf48b75cf40dd79342599e562240 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Tue, 21 Nov 2023 10:54:16 +0100 Subject: [PATCH 01/22] [rfc] Metadata, Summary and Motivation sections --- rfcs/0000-kuadrant-ci-cd.md | 86 +++++++++++++++++++++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 rfcs/0000-kuadrant-ci-cd.md diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md new file mode 100644 index 00000000..07a0936c --- /dev/null +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -0,0 +1,86 @@ +# Kuadrant CI/CD release process + +- Feature Name: `kuadrant-ci-cd` +- Start Date: 2023-11-21 +- RFC PR: [Kuadrant/architecture#0038](https://github.com/Kuadrant/architecture/pull/38) +- Issue tracking: [Kuadrant/architecture#0000](https://github.com/Kuadrant/architecture/issues/0000) + +# Summary +[summary]: #summary + +This RFC not only proposes a new release process for Kuadrant components, but also a new and more agile way of getting +the desired "artifacts" (images, manifests, etc.) into the hands of the users, devs, QE team and any other process that +needs them. + +# Motivation +[motivation]: #motivation + +The current process is not only slow, but also involves manual steps that are prone to human error. Its implementation +is also not very flexible, and it's not easy to add new steps or change the existing ones without replicating the same +code in different repositories. It also involves a convolution of different tools and services that are not easy to +maintain and that are not very well integrated with each other. + +# Guide-level explanation +[guide-level-explanation]: #guide-level-explanation + +Explain the proposal as if it was implemented and you were teaching it to Kuadrant user. That generally means: + +- Introducing new named concepts. +- Explaining the feature largely in terms of examples. +- Explaining how a user should *think* about the feature, and how it would impact the way they already use Kuadrant. It should explain the impact as concretely as possible. +- If applicable, provide sample error messages, deprecation warnings, or migration guidance. +- If applicable, describe the differences between teaching this to existing and new Kuadrant users. + +# Reference-level explanation +[reference-level-explanation]: #reference-level-explanation + +This is the technical portion of the RFC. Explain the design in sufficient detail that: + +- Its interaction with other features is clear. +- It is reasonably clear how the feature would be implemented. +- How error would be reported to the users. +- Corner cases are dissected by example. + +The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. + +# Drawbacks +[drawbacks]: #drawbacks + +Why should we *not* do this? + +# Rationale and alternatives +[rationale-and-alternatives]: #rationale-and-alternatives + +- Why is this design the best in the space of possible designs? +- What other designs have been considered and what is the rationale for not choosing them? +- What is the impact of not doing this? + +# Prior art +[prior-art]: #prior-art + +Discuss prior art, both the good and the bad, in relation to this proposal. +A few examples of what this can include are: + +- Does another project have a similar feature? +- What can be learned from it? What's good? What's less optimal? +- Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background. + +This section is intended to encourage you as an author to think about the lessons from other tentatives - successful or not, provide readers of your RFC with a fuller picture. + +Note that while precedent set by other projects is some motivation, it does not on its own motivate an RFC. + +# Unresolved questions +[unresolved-questions]: #unresolved-questions + +- What parts of the design do you expect to resolve through the RFC process before this gets merged? +- What parts of the design do you expect to resolve through the implementation of this feature before stabilization? +- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? + +# Future possibilities +[future-possibilities]: #future-possibilities + +Think about what the natural extension and evolution of your proposal would be and how it would affect the platform and project as a whole. Try to use this section as a tool to further consider all possible interactions with the project and its components in your proposal. Also consider how this all fits into the roadmap for the project and of the relevant sub-team. + +This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related. + +Note that having something written down in the future-possibilities section is not a reason to accept the current or a future RFC; such notes should be in the section on motivation or rationale in this or subsequent RFCs. The section merely provides additional information. \ No newline at end of file From 39ce2f55774a3a461c3f75c83f5570154213b94e Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Fri, 24 Nov 2023 17:12:10 +0100 Subject: [PATCH 02/22] [rfc] Guide-level explanation: Authorino --- rfcs/0000-kuadrant-ci-cd.md | 37 +++++++++++++++++++++++++++++++------ 1 file changed, 31 insertions(+), 6 deletions(-) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index 07a0936c..f50a28a5 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -23,13 +23,38 @@ maintain and that are not very well integrated with each other. # Guide-level explanation [guide-level-explanation]: #guide-level-explanation -Explain the proposal as if it was implemented and you were teaching it to Kuadrant user. That generally means: +## Current process -- Introducing new named concepts. -- Explaining the feature largely in terms of examples. -- Explaining how a user should *think* about the feature, and how it would impact the way they already use Kuadrant. It should explain the impact as concretely as possible. -- If applicable, provide sample error messages, deprecation warnings, or migration guidance. -- If applicable, describe the differences between teaching this to existing and new Kuadrant users. +Before we dive into the new process, let's take a look at the current one. The current process is based on the +independent build and release of each service (Authorino and Limitador), their respective Operators and the WasmShim +for then building and releasing the Kuadrant Operator. It's important that we follow this order because the +Kuadrant Operator depends on the WasmShim, and the Authorino and Limitador Operators. The process is as follows: + +### Authorino +A particularity of Authorino is that it follows the [Controller Pattern](https://kubernetes.io/docs/concepts/architecture/controller/#controller-pattern), +it's implemented as a Kubernetes controller thanks to the [Operator SDK](https://sdk.operatorframework.io/) and +[Kustomize](https://kustomize.io/). + +#### Artifacts +The deliverable artifacts are the [Authorino image](https://quay.io/repository/kuadrant/authorino) +and its [manifests](https://github.com/Kuadrant/authorino/blob/main/install/kustomization.yaml), the AuthConfig CRD and +role definitions. + +#### Build / Release +The build process is triggered by a particular GitHub Action that runs on demand (workflow_dispatch) named "Build and push image", +and to build an image version “v0.X.Y” of Authorino, the following steps are needed: + +1. Pick a (SHA-1) as source. +Create a new tag and named release “v0.X.Y”. Make sure to write change notes highlighting all the new features, bug fixes, +enhancements, etc ([example](https://github.com/Kuadrant/authorino/releases/tag/v0.9.0)). + +2. Run the GHA ‘Build and push images’ for the “v0.X.Y” tag. This will cause a new image to be built and pushed to quay.io/kuadrant/authorino. + +3. Create the release and release notes on [Github](https://github.com/Kuadrant/authorino/releases/new) using the tag from above, named: `Authorino vM.m.d` + +Notes: +PRs merged to the main branch of Authorino cause a new image to be built (GH Action) and pushed automatically to +quay.io/kuadrant/authorino: – the quay.io/kuadrant/authorino:latest tag is also moved to match the latest . # Reference-level explanation [reference-level-explanation]: #reference-level-explanation From 22805fdf38ce7773fc6edfef75930a6d151da5d9 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Mon, 27 Nov 2023 09:34:26 +0100 Subject: [PATCH 03/22] [rfc] Guide-level explanation: Limitador --- rfcs/0000-kuadrant-ci-cd.md | 87 +++++++++++++++++++++++++++++++++++++ 1 file changed, 87 insertions(+) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index f50a28a5..fc423095 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -56,6 +56,93 @@ Notes: PRs merged to the main branch of Authorino cause a new image to be built (GH Action) and pushed automatically to quay.io/kuadrant/authorino: – the quay.io/kuadrant/authorino:latest tag is also moved to match the latest . +### Limitador +In the case of Limitador, it's a completely different story. It's a Rust project, that it's split into a library (crate) +and a server. The server is a binary that uses the library, and it's built using the [Cargo](https://doc.rust-lang.org/cargo/) +build system. The library is published to [crates.io](https://crates.io/crates/limitador) and the server is published to +quay.io/kuadrant/limitador. + +#### Artifacts +The deliverable artifacts are the [Limitador service image](https://quay.io/repository/kuadrant/limitador) and the Rust +crate published to [crates.io](https://crates.io/crates/limitador). + +#### Build / Release + +##### `limitador` crate to crates.io + +1. A branch needs to be created, e.g. `release-0.5.0` +```sh +git checkout -b release-0.5.0 +``` + +2. Remove the `-dev` suffix from both `Cargo.toml` + ```diff +diff --git a/limitador-server/Cargo.toml b/limitador-server/Cargo.toml +index dd2f311..b555df8 100644 +--- a/limitador-server/Cargo.toml ++++ b/limitador-server/Cargo.toml +@@ -1,6 +1,6 @@ + [package] + name = "limitador-server" +-version = "1.3.0-dev" ++version = "1.3.0" +diff --git a/limitador/Cargo.toml b/limitador/Cargo.toml +index 3aebf9d..d17b92b 100644 +--- a/limitador/Cargo.toml ++++ b/limitador/Cargo.toml +@@ -1,6 +1,6 @@ + [package] + name = "limitador" +-version = "0.5.0-dev" ++version = "0.5.0" + ``` + +3. Commit the changes +```sh +git commit -am "[release] Releasing Crate 0.5.0 and Server 1.3.0" +``` + +4. Create a tag named after the version, with the `crate-v` prefix and push it to remote +```sh +git tag -a crate-v0.5.0 -m "[tag] Limitador crate v0.5.0" +git push origin crate-v0.5.0 +``` + +5. Manually run the `Release crate` workflow action on [Github](https://github.com/Kuadrant/limitador/actions/workflows/release.yaml) providing the version to release in the input box, +e.g. `0.5.0`, if all is correct, this should push the release to [crates.io](https://crates.io/crates/limitador/versions) + +6. Create the release and release notes on [Github](https://github.com/Kuadrant/limitador/releases/new) using the tag from above, named: `Limitador crate vM.m.d` + + +##### `limitador-server` container image to quay.io + +1. Create a branch for your version with the `v` prefix, e.g. `v1.3.0` +2. Make sure your `Cargo.toml` is reflecting the proper version, see above +3. Push the branch to remote, which should create a matching release to quay.io with the tag name based of your branch, i.e. in this case `v1.3.0` +4. Create a tag with the `server-v` prefix, e.g. `server-v1.3.0` +5. Push the tag to Github +6. Create the release and release notes on [Github](https://github.com/Kuadrant/limitador/releases/new) using the tag from above, named: `vM.m.d` +7. Delete the branch, only keep the tag used for the release + +##### After the release + +1. Create a `next` branch off `main` +2. Update the _both_ Cargo.toml to point to the next `-dev` release +3. Create PR +4. Merge to `main` + + ```diff +diff --git a/limitador-server/Cargo.toml b/limitador-server/Cargo.toml +index dd2f311..011a2cd 100644 +--- a/limitador-server/Cargo.toml ++++ b/limitador-server/Cargo.toml +@@ -1,6 +1,6 @@ + [package] + name = "limitador-server" +-version = "1.3.0-dev" ++version = "1.4.0-dev" + ``` + # Reference-level explanation [reference-level-explanation]: #reference-level-explanation From aae2047eb150f56e2abd7167e32b0480fc9c7e56 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Mon, 27 Nov 2023 10:04:17 +0100 Subject: [PATCH 04/22] [rfc] Guide-level esplanation: WasmShim --- rfcs/0000-kuadrant-ci-cd.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index fc423095..7214616b 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -143,6 +143,34 @@ index dd2f311..011a2cd 100644 +version = "1.4.0-dev" ``` +### WasmShim +A Proxy-Wasm module written in Rust, acting as a shim between Envoy and Limitador. It's built using an automated +GitHub Action and published to quay.io/kuadrant/wasm-shim. + +#### Artifacts +The deliverable artifact is the [WasmShim image](https://quay.io/repository/kuadrant/wasm-shim). + +#### Build / Release +The before mentioned GitHub Action is triggered by a push to any branch of the repository. It builds the image and +pushes it to quay.io/kuadrant/wasm-shim: and quay.io/kuadrant/wasm-shim:latest. + +In order to obtain a new release of the WasmShim, the following steps need to be followed: + +1. A branch needs to be created, e.g. `release-0.3.0` + +```sh +git checkout -b release-0.3.0 +``` + +2. A new tag needs to be created, e.g. `v0.3.0` and pushed to remote + +```sh +git tag -a v0.3.0 -m "[tag] WasmShim v0.3.0" +git push origin v0.3.0 +``` + +3. The GitHub Action will be triggered and will build and push the image to quay.io/kuadrant/wasm-shim:v0.3.0 + # Reference-level explanation [reference-level-explanation]: #reference-level-explanation From 0618e62ebc608874a7630d882c4dcb72576e0bc0 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Mon, 27 Nov 2023 11:34:36 +0100 Subject: [PATCH 05/22] [rfc] Guide-level esplanation: Authorino Operator --- rfcs/0000-kuadrant-ci-cd.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index 7214616b..079d0193 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -56,6 +56,30 @@ Notes: PRs merged to the main branch of Authorino cause a new image to be built (GH Action) and pushed automatically to quay.io/kuadrant/authorino: – the quay.io/kuadrant/authorino:latest tag is also moved to match the latest . +### Authorino Operator +The Authorino operator is similar to its operand, it fully follows the [Operator Pattern](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) +and to build its manifests relies on [Kustomize](https://kustomize.io/). + +#### Artifacts +Its artifacts are the [Authorino Operator image](https://quay.io/repository/kuadrant/authorino-operator), +[Authorino Operator Bundle](https://quay.io/repository/kuadrant/authorino-operato-bundle), +[Authorino Operator catalog](https://quay.io/repository/kuadrant/authorino-operator-catalog) and regarding its [manifests](https://github.com/Kuadrant/authorino-operator/blob/main/config/crd/bases/operator.authorino.kuadrant.io_authorinos.yaml) +the Authorino CRD and role definitions. + +#### Build / Release +To release a version “v0.W.Z” of Authorino Operator, these are the steps needed: + +1. Pick a stable (released) version “v0.X.Y” of the operand known to be compatible with operator’s image for “v0.W.Z”; if needed, make a release of the operand first. +2. Run the [Github Action Release operator](https://github.com/Kuadrant/authorino-operator/actions/workflows/release.yaml); +make sure to fill all the fields: + * Branch containing the release workflow file – default: ‘main’ + * Commit SHA or branch name of the operator to release – usually: ‘main’ + * Operator version to release (without prefix) – i.e. ‘0.W.Z’ + * Authorino version the operator enables installations of (without prefix) – i.e. ‘0.X.Y’ + * If the release is a prerelease + * Bundle and catalog channels (comma-separated) – usually: 'stable' +3. Run the GHA ‘Build and push images’ for the “v0.W.Z” tag, specifying ‘Authorino version’ equals to “0.X.Y” (without the leading “v”). This will cause the new images (bundle and catalog included) to be built and pushed to the corresponding repos in quay.io/kuadrant. + ### Limitador In the case of Limitador, it's a completely different story. It's a Rust project, that it's split into a library (crate) and a server. The server is a binary that uses the library, and it's built using the [Cargo](https://doc.rust-lang.org/cargo/) From 6df981d6f1cf1ace19fe6fc61419fed4e35b4c22 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Tue, 28 Nov 2023 11:55:37 +0100 Subject: [PATCH 06/22] [rfc] Guide-level explanation: Limitador Operator --- rfcs/0000-kuadrant-ci-cd.md | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index 079d0193..e887abd7 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -167,6 +167,40 @@ index dd2f311..011a2cd 100644 +version = "1.4.0-dev" ``` +### Limitador Operator +This operator is also implemented using the [Operator SDK](https://sdk.operatorframework.io/) and +[Kustomize](https://kustomize.io/). + +#### Artifacts +The deliverable artifacts are the [Limitador Operator image](https://quay.io/repository/kuadrant/limitador-operator), +[Limitador Operator Bundle](https://quay.io/repository/kuadrant/limitador-operato-bundle), +[Limitador Operator image](https://quay.io/repository/kuadrant/limitador-operator) and regarding its +[manifests](https://github.com/Kuadrant/limitador-operator/tree/main/bundle/manifests) the Limitador CRD and role +definitions. + +#### Build / Release +This build process is similar to the Authorino Operator one, but it's triggered by a different GitHub Action +(Build Images) which is a `workflow_dispatch` one, and it's triggered manually. The steps are as follows: + +1. Pick a stable (released) version “v0.X.Y” of the operand (Limitador) known to be compatible with operator’s image for +“v0.W.Z”; if needed, make a release of the operand first. +2. Create a branch named after the version, e.g. `release-0.7.0` +```sh +git checkout -b release-0.7.0 +``` +3. Tag the branch with the `v` prefix, e.g. `v0.7.0`, push the tag to remote +```sh +git tag -a v0.7.0 -m "[tag] Limitador Operator v0.7.0" +git push origin v0.7.0 +``` +4. Run the GHA 'Build Images' with the following parameters: + * Branch containing the release workflow file – example: `release-0.7.0`, default: `main` + * Operator bundle version (without prefix) - example: `0.7.0`, default: `0.0.0` + * Operator tag (with prefix) - example: `v0.7.0`, default: `latest` + * Limitador version (without prefix) – example: ‘1.3.0’, default: `0.0.0` + * Limitador operator replaced version (without prefix) - example: `0.6.0`, default: `0.0.0-alpha` + * Bundle and catalog channels (comma-separated) – example: `stable`, default: `preview` + ### WasmShim A Proxy-Wasm module written in Rust, acting as a shim between Envoy and Limitador. It's built using an automated GitHub Action and published to quay.io/kuadrant/wasm-shim. From b3dc2d7f1cd265233836d811d245314ffd739f22 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Tue, 28 Nov 2023 15:45:22 +0100 Subject: [PATCH 07/22] [rfc] Guide-level explanation: Kuadrant Operator --- rfcs/0000-kuadrant-ci-cd.md | 39 +++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index e887abd7..c017230c 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -229,6 +229,45 @@ git push origin v0.3.0 3. The GitHub Action will be triggered and will build and push the image to quay.io/kuadrant/wasm-shim:v0.3.0 +### Kuadrant Operator +The final step of the process is to build and release the Kuadrant Operator. This is a Go project that follows the +[Operator Pattern](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) following the [Operator SDK](https://sdk.operatorframework.io/) +and to build its manifests relies on [Kustomize](https://kustomize.io/) as the previous operators mentioned. + +#### Artifacts +The deliverable artifacts are the [Kuadrant Operator image](https://quay.io/repository/kuadrant/kuadrant-operator), +[Kuadrant Operator Bundle](https://quay.io/repository/kuadrant/kuadrant-operato-bundle), +[Kuadrant Operator image](https://quay.io/repository/kuadrant/kuadrant-operator) and regarding its +[manifests](https://github.com/Kuadrant/kuadrant-operator/tree/main/bundle) we can find the Kuadrant CRD, RateLimitPolicy +CRD, AuthPolicy CRD and role definitions. + +#### Build / Release +The build and release process of this operator is similar to the Limitador Operator one, but its dependencies are more, +including the WasmShim, the Authorino Operator and the Limitador Operator. The steps are as follows: + +1. A stable released version of Limitador Operator, Authorino Operator and WasmShim images are needed. + +2. Create a branch named after the version, e.g. `release-0.5.0` +```sh +git checkout -b release-0.5.0 +``` + +3. Tag the branch with the `v` prefix, e.g. `v0.5.0`, push the tag to remote +```sh +git tag -a v0.5.0 -m "[tag] Kuadrant Operator v0.5.0" +git push origin v0.5.0 +``` + +4. Run the GHA 'Build Images' with the following parameters: +* Branch containing the release workflow file – example: `release-0.5.0`, default: `main` +* Operator bundle version (without prefix) - example: `0.5.0`, default: `0.0.0` +* Operator tag (with prefix) - example: `v0.5.0`, default: `latest` +* Authorino Operator bundle version (without prefix) - example: `0.10.0`, default: `latest` +* Limitador Operator bundle version (without prefix) - example: `0.7.0`, default: `latest` +* WASM Shim version (without prefix) – example: `0.3.0`, default: `latest` +* Kuadrant operator replaced version (without prefix) - example: `0.4.1`, default: `0.0.0-alpha` +* Bundle and catalog channels (comma-separated) – example: `stable`, default: `preview` + # Reference-level explanation [reference-level-explanation]: #reference-level-explanation From 600527aafdf9a9a333b6e46871cb98f7c0e1a82d Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Wed, 29 Nov 2023 11:06:08 +0100 Subject: [PATCH 08/22] [rfc] Enclosing current process within a _details_ block --- rfcs/0000-kuadrant-ci-cd.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index c017230c..cc0f03bd 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -25,6 +25,9 @@ maintain and that are not very well integrated with each other. ## Current process +
+Summary of the current process + Before we dive into the new process, let's take a look at the current one. The current process is based on the independent build and release of each service (Authorino and Limitador), their respective Operators and the WasmShim for then building and releasing the Kuadrant Operator. It's important that we follow this order because the @@ -268,6 +271,8 @@ git push origin v0.5.0 * Kuadrant operator replaced version (without prefix) - example: `0.4.1`, default: `0.0.0-alpha` * Bundle and catalog channels (comma-separated) – example: `stable`, default: `preview` +
+ # Reference-level explanation [reference-level-explanation]: #reference-level-explanation From 92e70e9e927fa9645fa561d4c690b60e97ed13b9 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Fri, 1 Dec 2023 16:54:48 +0100 Subject: [PATCH 09/22] [rfc] Guide-level explanation: OperatorHub --- rfcs/0000-kuadrant-ci-cd.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index cc0f03bd..cc3237eb 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -271,6 +271,32 @@ git push origin v0.5.0 * Kuadrant operator replaced version (without prefix) - example: `0.4.1`, default: `0.0.0-alpha` * Bundle and catalog channels (comma-separated) – example: `stable`, default: `preview` + +### OperatorHub +The current 3 operators (Authorino, Limitador and Kuadrant) are published to [OperatorHub](https://operatorhub.io/). +This is done manually, copying the released bundle from each operator and opening a PR to the [community-operators](https://github.com/k8s-operatorhub/community-operators/) +and [community-operators-prod](https://github.com/redhat-openshift-ecosystem/community-operators-prod/) repositories. +The documentation for this process can be found in the [contribution section of OperatorHub](https://operatorhub.io/contribute). + +A brief summary of the process is as follows: + +1. In each community-operators repository, create a branch named after the name of the operator and its version, following +the template `[operator-name]-[semantic-version]`, e.g.`kuadrant-operator-v0.5.0` and create a directory within the +`operators/[operator-name]/[semantic-version]` path. +```sh +git checkout -b kuadrant-operator-v0.5.0 +mkdir -p operators/kuadrant-operator/0.5.0 +``` + +2. Copy the bundle and bundle.Dockerfile from the released operator branch to the `community-operators` repository directory just created. +```sh +cp -r [path-to]/kuadrant-operator/bundle/* [path-to]/community-operators/operators/kuadrant-operator/0.5.0/ +cp [path-to]/kuadrant-operator/bundle.Dockerfile [path-to]/community-operators/operators/kuadrant-operator/0.5.0/ +``` + +3. Create a PR to the `community-operators` (same for `community-operators-prod`) repository and follow the guidelines +exposed in the auto generated description of the PR. + # Reference-level explanation From 5f525b26ee7ab97b8b348e0682b592c60e7ceeda Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Tue, 5 Dec 2023 11:10:18 +0100 Subject: [PATCH 10/22] [rfc] Guide-level explanation: Current Process intro --- rfcs/0000-kuadrant-ci-cd.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index cc3237eb..011cd739 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -299,6 +299,27 @@ exposed in the auto generated description of the PR. +## New process +The new process ideally should be as simple as possible, and should be able to be triggered by any person, process and +set of events (particular commits, tags, merge, etc) that needs the artifacts. It also should be able to be repeated +in a consistent way and without the need of any human setting variables or parameters at the time of triggering it +(at least for the most common cases). + +Given our current process, we can identify some similarities and particularities between the different components: + +* All of them are built using a CI/CD tool (GitHub Actions) and published to a container registry (quay.io). +* Not all of them are built using the same build system (Cargo, Go, Operator SDK, etc.). +* 3 of them follow the Operator Pattern and are built using the Operator SDK (Authorino, Limitador and Kuadrant operators). +* 2 of them are Rust projects (Limitador and WASMShim). +* There's a dependency between the different components, Kuadrant Operator depends on Authorino and Limitador Operators, +and the WasmShim; while the before mentioned operators depend on their operands (Authorino and Limitador). +* There's no clear steps defined regarding the approval of the deliverables (images, manifests, etc.) and their +publication to our website, Github releases, OperatorHub, etc. + +Given the before mentioned points, we can identify some common steps that can be extracted and reused for all the +components, and some particularities that need to be addressed in a different way, but the overall +process should be the same for all of them in terms of triggering it and the steps that need to be followed. + # Reference-level explanation [reference-level-explanation]: #reference-level-explanation From 368d251e0f4563ca9f371200c56035a596eba0e3 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Thu, 7 Dec 2023 17:27:49 +0100 Subject: [PATCH 11/22] [rfc] Guide-level explanation: Option 1 Release File --- rfcs/0000-kuadrant-ci-cd.md | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index 011cd739..6555ef5a 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -320,6 +320,42 @@ Given the before mentioned points, we can identify some common steps that can be components, and some particularities that need to be addressed in a different way, but the overall process should be the same for all of them in terms of triggering it and the steps that need to be followed. +### Option 1: Release File +The first option is to create a file in the root of each repository that contains the information needed to build and +release the component. This file could be a YAML, TOML or simply a key-value file. The file should contain the following +information: + +* Component/s name/s and version/s (In the case of Limitador, it should contain the name and version of the crate and the name of the server). +* Dependencies name/s and version/s. +* Replace version (in the case of the Operators, this version is needed for the OLM upgrade process). + +This file should be updated every time a new release is made, and it should be committed to the repository to the release +branch. This file will be used by the CI/CD tool to build and release the component. In the case of the main branch, the +file will include the floating tag `latest` for its version and its dependencies. + +The CI/CD workflow will be triggered by a specific event (tag, commit, etc.) and will read the file and use the +information to build and release the component. The workflow will be the same for all the components, and it will +contain the following steps: + +Manual steps: +1. Create a new branch from the main branch or cherry-picking the commits that need to be released. +2. Update the release file with the new version/s and dependencies. +3. Commit the changes to the release branch. +4. Create a new tag with the new version following the semantic versioning vX.Y.Z. +5. Push the tag to the repository. +6. After the release workflow is done: + * approve the Github draft release and publish it. + * change the draft PR on OperatorHub to ready to review. + +Automatic steps on the CI/CD workflow: +1. Checkout the repository. +2. Read the file and extract the information. +3. Builds the manifests and images. +4. Create a draft release on Github with the information extracted from the file. +5. Build the component after running verification and tests. +6. Publish the component to the container registry. + + # Reference-level explanation [reference-level-explanation]: #reference-level-explanation From 491d620ad3e9519db558f4efa27ebe9427d927e4 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Mon, 11 Dec 2023 14:34:18 +0100 Subject: [PATCH 12/22] [rfc] Guide-level explanation: Release script --- rfcs/0000-kuadrant-ci-cd.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index 6555ef5a..69e4dbd7 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -356,6 +356,29 @@ Automatic steps on the CI/CD workflow: 6. Publish the component to the container registry. +### Option 2: Release Script +The second option involves creating a script that will be used with the same purpose of releasing the component's deliverables. +The script will be a bash script that will prompt the user for the specific information needed, such as the component's +name and version, its dependencies, etc. It will also fail if there's missing information or if the information provided +is not valid. The script will be the same for all the components, and it will contain the following steps: + +Manual steps: +1. Create a new branch from the main branch or cherry-picking the commits that need to be released. +2. Run the script and provide the information needed. +3. Commit the changes to the release branch. +4. Create a new tag with the new version following the semantic versioning vX.Y.Z. +5. Push the tag to the repository. +6. After the release workflow is done: + * approve the Github draft release and publish it. + * change the draft PR on OperatorHub to ready to review. + +Automatic steps on the CI/CD workflow: +1. Checkout the repository. +2. Run tests and verify manifests, bundle, etc. +3. Build the component/s. +4. Publish the component/s to the container registry. +5. Create a draft release on Github with the information provided by the user. + # Reference-level explanation [reference-level-explanation]: #reference-level-explanation From 407dfec534eaaa5fee6dc85b66c3e30662a49223 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Mon, 11 Dec 2023 14:35:00 +0100 Subject: [PATCH 13/22] [rfc] Guide-level explanation: Release workflow --- rfcs/0000-kuadrant-ci-cd.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index 69e4dbd7..3169e144 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -379,6 +379,31 @@ Automatic steps on the CI/CD workflow: 4. Publish the component/s to the container registry. 5. Create a draft release on Github with the information provided by the user. +### Option 3: Release Workflow +The third option is to create a Github Action that will be manually triggered by the user. The action will be the same +for all the components, but will prompt the user for the specific information needed, such as the component's name and +version, its dependencies, etc. It will also fail if there's missing information or if the information provided is not +valid. The action will contain the following steps: + +Manual steps: +1. From the Actions tab, select the Release action. +2. Introduce the information needed. I.e.: + * Component/s name/s and version/s. + * Dependencies name/s and version/s. + * Replace version (in the case of the Operators, this version is needed for the OLM upgrade process). +3. Run the action. +4. After the release workflow is done: + * approve the Github draft release and publish it. + * change the draft PR on OperatorHub to ready to review. + +Automatic steps on the CI/CD workflow: +1. Checkout the repository. +2. Build the component manifests and bundle. +3. Run tests and verify manifests, bundle, etc. +4. Build the component/s image/s. +5. Publish the component/s to the container registry. +6. Create a draft release on Github with the information provided by the user. + # Reference-level explanation [reference-level-explanation]: #reference-level-explanation From 22385d6bf5d19735df6179779c8881d24944e011 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Mon, 11 Dec 2023 19:19:33 +0100 Subject: [PATCH 14/22] [rfc] Reference-level explanation: Release File --- rfcs/0000-kuadrant-ci-cd.md | 182 ++++++++++++++++++++++++++++++++++-- 1 file changed, 175 insertions(+), 7 deletions(-) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index 3169e144..02836aa8 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -331,7 +331,7 @@ information: This file should be updated every time a new release is made, and it should be committed to the repository to the release branch. This file will be used by the CI/CD tool to build and release the component. In the case of the main branch, the -file will include the floating tag `latest` for its version and its dependencies. +file will include the next version to be released, following the floating suffix `-dev` for its version and its dependencies. The CI/CD workflow will be triggered by a specific event (tag, commit, etc.) and will read the file and use the information to build and release the component. The workflow will be the same for all the components, and it will @@ -407,14 +407,182 @@ Automatic steps on the CI/CD workflow: # Reference-level explanation [reference-level-explanation]: #reference-level-explanation -This is the technical portion of the RFC. Explain the design in sufficient detail that: +For the different options proposed, we'll be using [Limitador](https://github.com/Kuadrant/limitador) and the +[Limitador Operator](https://github/com/Kuadrant/limitador-operator) as examples since the former is the most different +from the rest of the components, and the latter is the most common one. -- Its interaction with other features is clear. -- It is reasonably clear how the feature would be implemented. -- How error would be reported to the users. -- Corner cases are dissected by example. +## Release File +For this option, will be using a YAML file named `release.yaml` that will be placed in the root of the repository. + +### Limitador +The file will contain the following information for Limitador component in the main branch pointing to the +`[next-version]-dev`: + +```yaml +server_version: 1.4.0-dev +crate_version: 0.6.0-dev +``` + +In order to prepare the release, the following steps need to be followed: +1. Create a new branch with the selection of commits that need to be released. +```sh +git checkout -b release-1.4.0 +``` + +2. Update the release file with the new version/s. +```yaml +server_version: 1.4.0 +crate_version: 0.6.0 +``` + +3. Execute the release script/makefile target. + TBD. This will use the information from the release file to update the Cargo.toml files and commit the changes to the + release branch with message "[release] Releasing Limitador crate 0.6.0 and Server 1.4.0". + +You will see the following changes: + + ```diff +diff --git a/limitador/Cargo.toml b/limitador/Cargo.toml +index 3aebf9d..d17b92b 100644 +--- a/limitador/Cargo.toml ++++ b/limitador/Cargo.toml +@@ -1,6 +1,6 @@ + [package] + name = "limitador" +-version = "0.5.0-dev" ++version = "0.5.0" + ``` + ```diff +diff --git a/limitador-server/Cargo.toml b/limitador-server/Cargo.toml +index dd2f311..011a2cd 100644 +--- a/limitador-server/Cargo.toml ++++ b/limitador-server/Cargo.toml +@@ -1,6 +1,6 @@ + [package] + name = "limitador-server" +-version = "1.4.0-dev" ++version = "1.4.0" + ``` + +4. Create a new tag with the new version following the semantic versioning vX.Y.Z. +```sh +git tag -a v1.4.0 -m "[tag] Limitador v1.4.0" +git push origin v1.4.0 +``` + +At this stage, the release workflow will be triggered and will do the before mentioned steps in the [Guide-level explanation](#guide-level-explanation). + +5. After the release workflow is done: + * approve the Github draft release and publish it. + * change the draft PR on OperatorHub to ready to review. + +### Limitador Operator +For the Limitador Operator, the release file will contain the following information in the main branch pointing to the +`[next-version]-dev`: + +```yaml +operator_version: 0.8.0-dev +limitador_version: 1.4.0-dev +replaces_version: 0.7.0 +``` + +In order to prepare the release, the following steps need to be followed: +1. Create a new branch with the selection of commits that need to be released. +```sh +git checkout -b release-0.8.0 +``` + +2. Update the release file with the new version/s. +```yaml +operator_version: 0.8.0 +limitador_version: 1.4.0 +replaces_version: 0.7.0 +``` + +3. Execute the release script/makefile target. + TBD. This will use the information from the release file to update the manifests and bundle files and commit the changes to the + release branch with message "[release] Releasing Limitador Operator 0.8.0". + +Between others, you will see the following changes: +```diff +diff --git a/bundle.Dockerfile b/bundle.Dockerfile +index 3aebf9d..d17b92b 100644 +--- a/bundle.Dockerfile ++++ b/bundle.Dockerfile +@@ -1,6 +1,6 @@ + LABEL operators.operatorframework.io.bundle.channels.v1=alpha + LABEL operators.operatorframework.io.bundle.channels.v1=stable +``` +```diff +diff --git a/bundle/manifests/limitador-operator.clusterserviceversion.yaml b/bundle/manifests/limitador-operator.clusterserviceversion.yaml +index 3aebf9d..d17b92b 100644 +--- a/bundle/manifests/limitador-operator.clusterserviceversion.yaml ++++ b/bundle/manifests/limitador-operator.clusterserviceversion.yaml +@@ -1,6 +1,6 @@ + apiVersion: operators.coreos.com/v1alpha1 + kind: ClusterServiceVersion +-metadata: +- name: limitador-operator.v0.8.0-dev ++metadata: ++ name: limitador-operator.v0.8.0 + spec: + apiservicedefinitions: + owned: +@@ -9,7 +9,7 @@ spec: + customresourcedefinitions: + owned: + - description: Limitador is the main resource that describes a rate limiting policy. +- displayName: Limitador v0.8.0-dev ++ displayName: Limitador v0.8.0 + kind: Limitador + name: limitadors.operator.kuadrant.io + version: v1alpha1 +@@ -17,7 +17,7 @@ spec: + - description: RateLimitPolicy is the resource that describes a rate limiting policy. + displayName: RateLimitPolicy + kind: RateLimitPolicy +- name: ratelimitpolicies.operator.kuadrant.io.v0.8.0-dev ++ name: ratelimitpolicies.operator.kuadrant.io.v0.8.0 + version: v1alpha1 + - description: AuthPolicy is the resource that describes an authentication policy. + displayName: AuthPolicy +@@ -26,7 +26,7 @@ spec: +replaces: limitador-operator.v0.7.0 +- version: 0.8.0-dev ++ version: 0.8.0 +``` + +4. Create a new tag with the new version following the semantic versioning vX.Y.Z. +```sh +git tag -a v0.8.0 -m "[tag] Limitador Operator v0.8.0" +git push origin v0.8.0 +``` + +At this stage, the release workflow will be triggered and will do the before mentioned steps in the [Guide-level explanation](#guide-level-explanation). + +5. After the release workflow is done: + * approve the Github draft release and publish it. + * change the draft PR on OperatorHub to ready to review. + +6. Create a `next` branch off `main` +7. Update the _both_ release files to point to the next `-dev` release +8. Create PR +9. Merge to `main` + +### Notes +* For any other specific version that is not meant for the actual release, the release file could contain the following information: +```yaml +server_version: 1.4.0-rc1 +crate_version: 0.6.0-rc1 +``` +or + +```yaml +operator_version: 0.8.0-qe-test +limitador_version: 1.4.0-qe-test +replaces_version: 0.7.0 +``` -The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. # Drawbacks [drawbacks]: #drawbacks From 77494bd0f909a86ad64842a43e38592409c334ec Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Mon, 11 Dec 2023 19:38:21 +0100 Subject: [PATCH 15/22] [rfc] Reference-level explanation: Release script --- rfcs/0000-kuadrant-ci-cd.md | 149 ++++++++++++++++++++++++++++++++++++ 1 file changed, 149 insertions(+) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index 02836aa8..259f0224 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -583,6 +583,155 @@ limitador_version: 1.4.0-qe-test replaces_version: 0.7.0 ``` +## Release Script +The release script process will be similar to the release file one, but instead of updating a file that will be used +as input for the needed script or workflow, the user will be prompted for the information needed to build and release +the component. + +### Limitador +In order to prepare the release, the following steps need to be followed: + +1. Create a new branch with the selection of commits that need to be released. +```sh +git checkout -b release-1.4.0 +``` + +2. Run the release script/makefile target. + This will communicate the user the parameters needed when ran without any, or it could prompt the user for them. + When successfully ends applying the changes, it will commit them to the release branch with message + "[release] Releasing Limitador crate 0.6.0 and Server 1.4.0". + +```sh +./release.sh limitador-server=1.4.0 limitador-crate=0.6.0 +``` +You will see the following changes: + + ```diff +diff --git a/limitador/Cargo.toml b/limitador/Cargo.toml +index 3aebf9d..d17b92b 100644 +--- a/limitador/Cargo.toml ++++ b/limitador/Cargo.toml +@@ -1,6 +1,6 @@ + [package] + name = "limitador" +-version = "0.5.0-dev" ++version = "0.5.0" + ``` + ```diff +diff --git a/limitador-server/Cargo.toml b/limitador-server/Cargo.toml +index dd2f311..011a2cd 100644 +--- a/limitador-server/Cargo.toml ++++ b/limitador-server/Cargo.toml +@@ -1,6 +1,6 @@ + [package] + name = "limitador-server" +-version = "1.4.0-dev" ++version = "1.4.0" + ``` + +3. Create a new tag with the new version following the semantic versioning vX.Y.Z. +```sh +git tag -a v1.4.0 -m "[tag] Limitador v1.4.0" +git push origin v1.4.0 +``` +At this stage, the release workflow will be triggered and will do the before mentioned steps in the [Guide-level explanation](#guide-level-explanation). + +4. After the release workflow is done: + * approve the Github draft release and publish it. + * change the draft PR on OperatorHub to ready to review. + +5. Create a `next` branch off `main` +6. Update the _both_ release files to point to the next `-dev` release +7. Create PR +8. Merge to `main` + +### Limitador Operator +In order to prepare the release, the following steps need to be followed: + +1. Create a new branch with the selection of commits that need to be released. +```sh +git checkout -b release-0.8.0 +``` + +2. Run the release script/makefile target. + This will communicate the user the parameters needed when ran without any, or it could prompt the user for them. + When successfully ends applying the changes, it will commit them to the release branch with message + "[release] Releasing Limitador Operator 0.8.0". + +```sh +./release.sh limitador-operator=0.8.0 limitador=1.4.0 replaces=0.7.0 +``` + +Between others, you will see the following changes: +```diff +diff --git a/bundle/manifests/limitador-operator.clusterserviceversion.yaml b/bundle/manifests/limitador-operator.clusterserviceversion.yaml +index 3aebf9d..d17b92b 100644 +--- a/bundle/manifests/limitador-operator.clusterserviceversion.yaml ++++ b/bundle/manifests/limitador-operator.clusterserviceversion.yaml +@@ -1,6 +1,6 @@ + apiVersion: operators.coreos.com/v1alpha1 + kind: ClusterServiceVersion +-metadata: +- name: limitador-operator.v0.8.0-dev ++metadata: ++ name: limitador-operator.v0.8.0 + spec: + apiservicedefinitions: + owned: +@@ -9,7 +9,7 @@ spec: + customresourcedefinitions: + owned: + - description: Limitador is the main resource that describes a rate limiting policy. +- displayName: Limitador v0.8.0-dev ++ displayName: Limitador v0.8.0 + kind: Limitador + name: limitadors.operator.kuadrant.io + version: v1alpha1 +@@ -17,7 +17,7 @@ spec: + - description: RateLimitPolicy is the resource that describes a rate limiting policy. + displayName: RateLimitPolicy + kind: RateLimitPolicy +- name: ratelimitpolicies.operator.kuadrant.io.v0.8.0-dev ++ name: ratelimitpolicies.operator.kuadrant.io.v0.8.0 + version: v1alpha1 + - description: AuthPolicy is the resource that describes an authentication policy. + displayName: AuthPolicy +@@ -26,7 +26,7 @@ spec: +replaces: limitador-operator.v0.7.0 +- version: 0.8.0-dev ++ version: 0.8.0 +``` + +3. Create a new tag with the new version following the semantic versioning vX.Y.Z. +```sh +git tag -a v0.8.0 -m "[tag] Limitador Operator v0.8.0" +git push origin v0.8.0 +``` + +At this stage, the release workflow will be triggered and will do the before mentioned steps in the [Guide-level explanation](#guide-level-explanation). + +4. After the release workflow is done: + * approve the Github draft release and publish it. + * change the draft PR on OperatorHub to ready to review. + +5. Create a `next` branch off `main` +6. Update the _both_ release files to point to the next `-dev` release +7. Create PR +8. Merge to `main` + +### Notes +* For any other specific version that is not meant for the actual release, the release script could be used with the following parameters: +```sh +./release.sh limitador-server=1.4.0-rc1 limitador-crate=0.6.0-rc1 +``` +or + +```sh +./release.sh limitador-operator=0.8.0-qe-test limitador=1.4.0-qe-test replaces=0.7.0 +``` + +* This option could be combined with the release file one, so the script could read the information from the file or prompt the user for it. + # Drawbacks [drawbacks]: #drawbacks From ae46dde7d752180f174162964d49fe46ffa43a1c Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Mon, 11 Dec 2023 19:56:39 +0100 Subject: [PATCH 16/22] [rfc] Reference-level explanation: Release workflow --- rfcs/0000-kuadrant-ci-cd.md | 57 +++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index 259f0224..762af5e5 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -732,6 +732,63 @@ or * This option could be combined with the release file one, so the script could read the information from the file or prompt the user for it. +## Release Workflow +The release workflow process, besides bringing the same benefits as the other ones, will also allow to trigger the +entire process from a Github Action on demand, which it also could be seen as a complement to the other options. + +### Limitador +In order to prepare the release, the following steps need to be followed: + +1. From the Actions tab, select the Release action. It will prompt the user the following parameters: + * Server version. I.e.: `1.4.0` + * Crate version. I.e.: `0.6.0` + * Release branch/commit/tag. I.e.: `release-1.4.0` + * Release tag. If not provided, it will be generated from the version. I.e.: `v1.4.0` + +2. Run the action. +This will commit the changes to the release branch with message "[release] Releasing Limitador crate 0.6.0 and Server 1.4.0". +It will verify the manifests, build the images and publish them to the container registry. It also will draft a release +on Github with the information provided by the user. + +3. After the release workflow is done: + * approve the Github draft release and publish it. + * change the draft PR on OperatorHub to ready to review. + +The following steps can be automated by the release workflow, but they could be done manually as well: +4. Create a `next` branch off `main` +5. Update the _both_ release files to point to the next `-dev` release +6. Create PR +7. Merge to `main` + +### Limitador Operator +In order to prepare the release, the following steps need to be followed: + +1. From the Actions tab, select the Release action. It will prompt the user the following parameters: + * Operator version. I.e.: `0.8.0` + * Limitador version. I.e.: `1.4.0` + * Replaces version. I.e.: `0.7.0` + * Release branch/commit/tag. I.e.: `release-0.8.0` + * Release tag. If not provided, it will be generated from the version. I.e.: `v0.8.0` + +2. Run the action. +This will commit the changes to the release branch with message "[release] Releasing Limitador Operator 0.8.0". +It will verify the manifests, build the images and publish them to the container registry. It also will draft a release +on Github with the information provided by the user. + +3. After the release workflow is done: + * approve the Github draft release and publish it. + * change the draft PR on OperatorHub to ready to review. + +The following steps can be automated by the release workflow, but they could be done manually as well: +4. Create a `next` branch off `main` +5. Update the _both_ release files to point to the next `-dev` release +6. Create PR +7. Merge to `main` + +### Notes +* For any other specific version that is not meant for the actual release, the release workflow could be executed with +custom paramaters. +* This option could be an enhancement to the previous ones, and work as a complement to them. # Drawbacks [drawbacks]: #drawbacks From cdd821206836e8012338fb4449d0083477480078 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Mon, 11 Dec 2023 20:16:06 +0100 Subject: [PATCH 17/22] [rfc] Drawbacks --- rfcs/0000-kuadrant-ci-cd.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index 762af5e5..d88fc528 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -793,7 +793,10 @@ custom paramaters. # Drawbacks [drawbacks]: #drawbacks -Why should we *not* do this? +* It will require some effort to implement the new process. +* There's still some other-than-code steps that need to be done manually, such as the approval of the Github draft release, +the approval of the OperatorHub PR, communication (blogpost, slack, etc). +* It will need a thorough verification and testing to ensure it works as expected. # Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives From 8dff153c827daa7c27e20b4585275a892e58fc94 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Mon, 11 Dec 2023 20:16:39 +0100 Subject: [PATCH 18/22] [rfc] Rationale and alternatives --- rfcs/0000-kuadrant-ci-cd.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index d88fc528..aec66447 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -801,9 +801,10 @@ the approval of the OperatorHub PR, communication (blogpost, slack, etc). # Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives -- Why is this design the best in the space of possible designs? -- What other designs have been considered and what is the rationale for not choosing them? -- What is the impact of not doing this? +* The current process is not consistent and it's not easy to follow without learning the details of each component. +* It will allow us to create a set of common steps that can be reused for all the components. +* It will be easier to maintain and extend. +* It will allow other non-technical people to trigger the process. # Prior art [prior-art]: #prior-art From b30c092b3b0286a6f39454090c89322093f1d106 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Mon, 11 Dec 2023 20:16:56 +0100 Subject: [PATCH 19/22] [rfc] Prior art --- rfcs/0000-kuadrant-ci-cd.md | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index aec66447..4355be42 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -809,16 +809,10 @@ the approval of the OperatorHub PR, communication (blogpost, slack, etc). # Prior art [prior-art]: #prior-art -Discuss prior art, both the good and the bad, in relation to this proposal. -A few examples of what this can include are: - -- Does another project have a similar feature? -- What can be learned from it? What's good? What's less optimal? -- Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background. - -This section is intended to encourage you as an author to think about the lessons from other tentatives - successful or not, provide readers of your RFC with a fuller picture. - -Note that while precedent set by other projects is some motivation, it does not on its own motivate an RFC. +* [Authorino release process](https://docs.google.com/document/d/1tLveyv8Zwe0wKyfUTWOlEnFeMB5aVGqIVDUjVYWax0U) +* [Limitador release process](https://github.com/Kuadrant/limitador/blob/main/RELEASE.md) +* [Limitador Operator](https://github.com/Kuadrant/limitador-operator/tree/main/.github/workflows) and +[Kuadrant operator workfdlows](https://github.com/Kuadrant/kuadrant-operator/tree/main/.github/workflows) # Unresolved questions [unresolved-questions]: #unresolved-questions From f68ce4487527621654fc2326c4848e2c06557659 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Mon, 11 Dec 2023 20:17:29 +0100 Subject: [PATCH 20/22] [rfc] Unresolved questions --- rfcs/0000-kuadrant-ci-cd.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index 4355be42..edda7e17 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -817,9 +817,10 @@ the approval of the OperatorHub PR, communication (blogpost, slack, etc). # Unresolved questions [unresolved-questions]: #unresolved-questions -- What parts of the design do you expect to resolve through the RFC process before this gets merged? -- What parts of the design do you expect to resolve through the implementation of this feature before stabilization? -- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? +* How to handle the release of the website? Should it be part of the release process? In particular the docs part. +* Communication of the release should be triggered automatically? +* Should it be the 3 options combined? Maybe we could start with the release file and then add the release script and +release workflow as enhancements. (?) # Future possibilities [future-possibilities]: #future-possibilities From 8d6a9648ae79d4de204a718a7b0a00a15e3ab3b5 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Tue, 12 Dec 2023 18:11:19 +0100 Subject: [PATCH 21/22] [rfc] Adding kuadrant components image --- rfcs/0000-kuadrant-ci-cd.md | 3 +++ rfcs/0000-kuadrant-cicd-release/.DS_Store | Bin 0 -> 6148 bytes .../kuadrant-components.png | Bin 0 -> 13542 bytes 3 files changed, 3 insertions(+) create mode 100644 rfcs/0000-kuadrant-cicd-release/.DS_Store create mode 100644 rfcs/0000-kuadrant-cicd-release/kuadrant-components.png diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index edda7e17..1b5840a3 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -307,6 +307,8 @@ in a consistent way and without the need of any human setting variables or param Given our current process, we can identify some similarities and particularities between the different components: +![](0000-kuadrant-cicd-release/kuadrant-components.png) + * All of them are built using a CI/CD tool (GitHub Actions) and published to a container registry (quay.io). * Not all of them are built using the same build system (Cargo, Go, Operator SDK, etc.). * 3 of them follow the Operator Pattern and are built using the Operator SDK (Authorino, Limitador and Kuadrant operators). @@ -813,6 +815,7 @@ the approval of the OperatorHub PR, communication (blogpost, slack, etc). * [Limitador release process](https://github.com/Kuadrant/limitador/blob/main/RELEASE.md) * [Limitador Operator](https://github.com/Kuadrant/limitador-operator/tree/main/.github/workflows) and [Kuadrant operator workfdlows](https://github.com/Kuadrant/kuadrant-operator/tree/main/.github/workflows) +* [Current release process](#guide-level-explanation) # Unresolved questions [unresolved-questions]: #unresolved-questions diff --git a/rfcs/0000-kuadrant-cicd-release/.DS_Store b/rfcs/0000-kuadrant-cicd-release/.DS_Store new file mode 100644 index 0000000000000000000000000000000000000000..501fbf55a6d1a36a58ee91a43e105bf86ec169db GIT binary patch literal 6148 zcmeHKyG{c^3>=3Pk!aFExjz6Bf3S*@f|?(IJVZgrA(Hf0g`edgVEiEBbV*BrY{@&f zUe8)L#rX_CCi~?bFa|K9E8;_!zUjGo&jt|@BAs`<;|Uw=aDzoJ`*c9LS9rmm%w>n) z;1zFZc;CwI+~St|4W94U&0@Z8=47&@d;){RSJ>$y8BGOJfm9$BNCi@XqXOD{X`@TW zTvLHmAQd<&px=i=SFC}pqkTHK*a$!zGHk|YnBGIx<2NrxKkiF=B|*884An z16xO@L##6IiOLcaidc2Vi={)VW3H({D$rHn!nb4X|1-6A;Ez#6B&aL2uMhnk_ZV2VF=$zK;K*S)?4@9uj;#1x2pX^&OZCBwf5R; zKhIj{EFYY)v5@~&jHJK|cr9{H1x|N1_&X8DMN_45-XtI8uJ_C=I`yKE;$GORGw zmor)&6o|oTh@B1#+~)WBDd@BGdZ)hi)Vef^wOJ*V0k-rK`UgRLk#S$jry=LcKS@`W zOHct0RLQ7frCe{@TYu$}y?m5zkXP+VigYfhI_SV8@@VBTlGh=~KCzGz>>`m&X!F+k zNWA2e&GB;Lc4YXH?y)t!AYgN|k~wewD`0{l!b}0}0~i)d`)r2qm1xZXCHu^DjM_W* zs3W?O5u!+SD|G0Z(kNBJvnXf@Aix4X`pov4JE}eb6uLZ(5ve}cxurBJZHD&tTrS@H zyP#$;-*LR-;9CfzULNuv^z8)mKWCQ$Q!qQgU&~3|gGDT%$el*Qo0FC9 zw8bGW3fGS`>9%#fG%x>NcCQL!x?A;$y6~9F& zV3f1AeVS1){pGl2!O6N4XW@*k@xP7}mf#HYZA-(4_6G1eJf8Z8=@Ak* z-;&zv%Jg=C^WJr4dtE}+pG54W9GcGaFa{s9NqR=iF}VxssxjNUmWgRJV3|LNPCGo3dVsE+O3SgZz^e~#|FL^N6ZAI}&0Zq5G0BcQ z-uJhH>#?Ba?K}#%)_D3b5_Q`t~#{%W27fsI3ip;-R*^1of zcYWmOO@EAe?+)1fwh&T9TKw>sJ%qOJ8eCkc7B&?GU>5fl&{4sp^BI1B#`Fz`!0$f# znLhHj*QvV(NwkyXYjI7w<91uaSM?Uh!@Hk~~z>21exPML{{y zxD}SP!>uoTZn$@lmuuFKRS^ARRUP&0bSTV?>0j13dcwKBU2ro4)be6``s0MwIn^p# z1sLf@E=}83VdM*2WNzeIOuSF)*`+?CKrgD7fA&UX{;FSf)8Ug@;`F_y<@5;jdoC@^EgJy9kt*g}ZmUX5+(HVai77QH{qaz7Y>vl1-}?maxsptXR(yW85Ss%Fi#ZLRP=?=j)=|`_s8D0t1&fRkj7*8$BII$Zt(l=P2@? z4D&<~ROlJ1!Fy%9==ju_a(ih+SpFW1)Kc&e$@BIiI@b4g12OFGi|QP^7aW*j7j4*T zIOuz;6Tj9o5!>Op#p*D17YW{UCVRK0e~aSu76dy#wvFu$0qb;)XIDQ3dF$!B&Lz@^ zvPwbOCoft0WAdBt+UJ*7&>>0w(-X3Y;ejAH`ep^l8IsZ7(D6?b^ioJr%26f!cG|b`` z$O(*6uY$WtT}@%J4_rK$AkrNXSr9f%7le5jQbUC0+JwRpJ9v_lx$-f{4Z~JSiABtZ z1N3sS<=nF?vw9krA1joT7Y;UqF{=rMD3=>g{2z|w6)Y6GLy-Dho2UvNWG?J(9IfYF zH6*#{ZDRt3`4;g<8H|arIwuF#AT--9H5n%e>rQ-RHG|E;Fxe%>sl?F?y`u|*1)uXj zbCsB6#0wtAbcF7+)zgx-)*5Z1MwoZd{cU<=79GkQYFGu5aD%#EoO{DPL1KJ^<20c& zC~!@SEBu97w|I!P2cHPyy-{k~g>^qkL?Xsf}FszE3@6{C47j{MdpxOeKx!+dtsd2VEu}+a(j$!A9%k$(R zlBfcBoQmApnVP9X(&WY@1wQN_FDV#E$e?|e1Tg^RC8y@>dwAJ<=seML zo<5dpdtiylOTxBRI$NO%y3`90^DfI-6^b>Nv}>C=i-tJS$iIfPTO4(xpLQn(G|}Du zcIC*OgWpnY)DXoC@;-@5o)oTFkDYK|1VtIw0vySE2MJUobZvB-$*}e$nov?|4%dxOsgCi2-hrv)uhaUL`n% z?@oPA(~0a8cvmA+eK{vI)&vW4#pk3Mk+6I2xz^;Xc#v<&RMv0%v^@I>sX}n@{4_4; zhqyOh>fvaM+Ouyky(siWTV=-?cc(v4Q0(8tu!V``EKhj!Gw&2$*Vos!>~K!m2`8bq zlOZZFt7fn4*Ol#KL}pM2=)LEQSg4S@eIJp}2JRITNsCj`%>(jC-ayq&9r}EhZ5{In z%#5gYMr*!9l9mAJ;=n`)K`r&5Vuu>^SW!&>X{q5rJ{j`T7Ps!3qlPxiurf5fPN18` zhKw!Uklrp!1mQ+LO@VDT+Xiv+z6uK53MIZ65ItyG-BHj`_ERqSfotp}&U9%(^gyDA z&4}FV<>eCD&#N>)nls5DbCAtoPUn1z9@k+;<^Bz?y1AJ!NN`Gi(#^5`X|I-JE(C7! z0NYf_!qoORO*UXbdL^{Pm`aVe%e%#9m_tGQlYTByi7KNlA__(#H+YTIa<(EgHv=`6pw*v}Tzz;E=vyoIDkHNCv}Y_!U1X)AG}$?EH* ztA+)fW++}G>_sR@upc<+UOai27pTycWRhh3*_O_9HcIv|HM{t&>E+|Furw<73Fc~^ z*Hm0GGriEkFhsUe0ermrlStD$@FhGZwZ}jaA;9cqeIxCb#m%9!qFn(d6wHzlZFnm+OF^ zw&DkE^j_gVm@HWAr+>%gO)gY{tHNJ$?rAo{Q~2Bp{n)@QN@owe@JfwPE8}5(7alrQ zga1lVK$(aw{#C%-5t$oOO)73|$VoM|-R863+R(05MvbJ=3Qne+A+lhK)Nmz&d-O8g z*c6M&FLi44T@S!Cu)Gxsdw!1lxoD{$ zG6xgeF4B8Bu8u%?woEjJi-A80xpP;3lq%U7AY0CXrZBU(6@3u!oxU$tn&3k#tk#Jf zUWfR8_eT}^qpHheMZUbac<6h1cv-ac}M}{_;w&Mx>A<8CSv$Vj5?bNcfFpfA)v8TfKcB1ZVV9jBfIra;hcb zavrPu_@AOsEf)+z9TZBy_h<&U2D;4Hr!~PF{tliwgR-y3t{!!TbPjAr49om8x8*(adw!hkG}#za~je-+Mj5Lil~?026LwRE?GepO3I>W@#{*0 zBLpM{?+gl6FaN|51@`%VOYwDe?jm>gc;|pB!c2Sr`3q+37ESQo9rm7wr9;uL-T|m0 zPtg1=<&WHFg6??G*@Rc`RHQ@Xb4~!vMA8)3TR-kPgYu}CFAV?w%P^}k6o4g0WLoA0 zAL$R5zh37>_V%@hz{BErCwfZDdloNl>?C@iS!Cg$S@G2y{Tid00?33B`0JqV6#~(r z;JLsRxT+fJu0G;VZE~=i&!0&H(akzJ6jumo%x<0tTn2pRw4yPcKq>c3fSxb}n-}z_ z&%4xR+t|+&fvoYT5{C{XoAM`obc_)E3QY$v9wO8&;erUyvRMN!1!w^M`LxPTqCb$D zW}tArLM-ib2a`jasH%%lhq#u@6Z`*sQq(+#JT zn64%SJQy&ALrwjJMSRKK{2alvJymq#ts`=kq|uRSq09Wico2170|t0ea8w z*Jx*2zbFz_tW+<*i(yWT8tfh(N+)j~B?K$5$oWx;8xUse2t#XF<4=S1Tf;w1L=+yn z;&ORccR>ffa6w70Pj8Mk0D;nT4li6ReeXHPxi}o~EnsGJA#hP%|46|SzZZX-R&H}7 z-#(Ux9zpLjz42QXISn4^7WBzA@D-gviz&2^{IyuhmxD*yguQwy zri5Tvi+r&6^p^rerYcQ4E=fKaTzm7C>6YIUv8}%0k+u|hs@xKrcKxLm?uc#NW3diF zi5aWT+zRQp1HuUgB__lyp7$MKl1KJNzRTSBbgiELL006T9;Z^^HOr@!6F=VTeb`4( z(k+RaaDLJx`phIx+c?4)czSRSYXE%^tQ+WCOi&ufs^G@w(m;XEWG~hO^l>)j+Ymut zH&`BfhgM&y4kEO*f_>oo={K2I*44eEE@*>$!G!Gj zJ$Dq&g>w2~_1F=!H~otM(aYh}K>^U{G+2?oEFFAbB`F@{S%DMS zlV<|j_`c*LXP^YY@JZTrE8MIc&kKN!nEWR~KKN+eCZk=u;C@oG$7u-0EHacABLRVW@@I-q;*Bi;2 zi+4gyN!k=#HYVs!(OTe84h8bhHy>_3kshPwbGjgI_C~|!b5w(CIPXyXa^;B&DW?Yf zBI5Fa@H7G^&HP`V?*9Xb(7rptT6(d97b)dcAH;iw-$F83sAa&&%rj--thzTSxrGx% z!m}u!C5r^m*xY2rr6fPQzAlB1O6ME^i?CKjpKRQsOz&FB5eN1gtzk`5J0P(Q`!8I0@p^BawJ-Gn zoYxb$j9t0EJDsHfeP8!&Sy zbqOFAR7qYn$1vcvrL?BJV|Bq_*ZyHFYaoI3sPlIvQzsI}yHb#D~7)Ku5EKYtlw zdwT2gxyYFmXXr);*x0zCET3a0!C-Tg*4Og3%EA!O{zUb0-?4sKsh<#E{~Uva6Z-4i zf>LmOAlq~!=s;Z-po&$GZJK^S%GFrvSL=v_`-PU7RP#9q>!p~1)6yq9??FGMa2Uuv zTB|;dvdr_f9hmrzGYkAiQHI#HzZ7ll|^^u>m8OuvB%a7@HkS%spA*z#}04@ z7Y2;JbbL_ITOmd4Y0qcZVBCu;8l;J8OxgRD!0s8VyCP~T9_{4EQ-n)S51-FRpf4_m zm$M7Hsq$LWjbZ*X*Zsn|&$-#=!sUZTPHs>8c+Htv8F_+k69*%0%w6HxBT2ajxO%NR zxud0f`6OaY|4O8S;Gtk zaw?YB_9p8O9=-RqzKsJfXZQ7Avo$fk5-u9Vz8vV*hj*G#{-SrO5b!r7y&$9waO7B?^I%gP=)kFP3AX+4Y> z+wJZF?|M&omi`9`xwxeyTM)jPQ26CMF9YcaOWd}Iu>H_5p=A_2AWbI7$%4Gh0@0QT z(W{>PwS^eY-`{--&kbhQd?nrO^-sRn+h+myOU0$lomfdq3fT`qQ7ec=&LmHh#97q; zT{80T(J{cOsq-?9oA){-knV}bQ_wS7>hN4`r97tW7Mxc$i5K-q#iFmmJ5OZNY*?rD zHo2@S8)+@`C*4) z_YD_A=Euh>T3(Cq^k$%nMx^UxCn7z(`-Aq;-Zh(Dd;+%=9@33_D0-}KYP@elLRNc+ zLf7LR?c4^d>+^kG`%QBtdkQrGC(r*@5K7Ii{5v}~jc6UrDHlKKGqed-N#od$Pn(TI zUACN7t8Ks5Iq}m$xEGtYtO<$CB(#L|RgPS4E*?LZVOO@^Ia%WmUs#sdkJ>PU3(A zL6Y?e3W3k0*W47!OR7<9tF6@P%1K=c_r5qk*s8;ADQ6RFBpBl+i7zx9{wW65n_q2_ zf>(IcwezNx7R~|AhwE@3^V};egy)wYN)pcb9$G#33MMl+d(*ZkL`ptn+EgbPL>uj| zsDqMNkCBg{#Zq?wY492P2M)7j?8$26h^X}LRF;$J_gmwdbA+AQ995i|ujo7m?FTOk z?hjkb@g=tOj37ib4s#^OBBrrGQ~W%?L8PvPFv$3q62yly*J8z15N<%>@( zEiZA1V5ggp5FIkZ2j^w$A)4gPFcYA0iztQAU_zvT_(^Pva|tSR1F#s`ywqlnCh;&iGv|A;V^q@ER%>-?BfMk9Yr$H>4;HBoEsTHkQ zU!F~F%|gmIHh+|HR2ZXXhU%_yQY z;JJOs*Y74feBB??3;k}Ia>>%J94SuMfh+egrC7d^0*^i{h55h!0@tcYr+)Z8R9lpK zSx!O<-rK&M){m6PFAn=Y_G)S}t49j|J|Fh~%no0zA{E0-?ceMyRTAd~u9fmc`=*}L z`cevs_1@BY(|PtiJ+MvJT2?Y^ToEic@WTC)88Jp8KK7g0!ht^!#SB-8u)tfqD;~ot zs?7!ipCmjZ+mn9HdWXgYF-kI*p&Jo&XmZ#GCzP&)Hd>PCj%OkJ%cPe;U*1~3rsdzN zgf_5bWsi1(=g1O42!=UbYGW*I6eL+-LjnlxAz?j3M5ez)^)3rIA1l>Tk0t6$SnuD3 zyrbO@5FfiP%G3A&I$3BAbf-ukI8IQCLUiSUe#iAUA$H!^9n=C3e3WX9LYQp@4az$3ewTxON&>yF8(f$R;T9Oi zlcq4=+~QRkWR!FPHW{EMzs#_Jmiv6VdkW{*`SU~@dgP%oBBmbg9ZZ%cyyX~+c%EWBm#?4uX>E2bkqOI@JVf=!8B zK*L>v&9e&nH?H-*n1I-c?l6IcTg-(ZhBtqo)W8heNvb&wqspFwA0mn77UGA!=5#fd zwu4)1r0Z^{eQTp88gvu%PaHG6FhnKTA>NA??(jctB?Ra$FZ)|aqe+A#JKH)z=?;aU zlA)I{*W5YsTYAhn&2&g)}{+D{M)H;58}``j}a*i^GC*yKurNH@loM(CS5HF z2&Bs)hF0Uh?%v1L8NW=UAGBZyAu0n7f8n9>8w|@`J zc3O(=Ev$pv4QgVa1_teQ|NH!PNDso;*{fGnTS~4uQ%hUHg?OYH;ujqtd0Y;sn`-Dy zTZlUB$3mCsj3z!)(}WGOBNeL* z7Bi@W=m)o}qHPK3XEE0=#@vXGy^-A$$|`+d8FuUUMFT>>Pg1`mjzs##ok?=k-n%BU z!ci1xl)(Lx%v2jo6>WJpV*ZZT$P7>%=*^(r+$3FO1Hz-kc8C{!%Y8%Aqg918^H3*6 zKjOVfnyyU}f* zu#^K*YDJcoe4ZH+{^>|iJ=T8t@JKOz&~g z$44oRhqF*tdOYmH*XacZ?95~4U)!6xjTmk6*Y>NehIJh{4Czu^LSt?mAiBfZk?!H%GUgN zVjlJ_N^VNz3q9wA^3wfGZ@?-~lU%dm;pbks$QmrYS+srY1FhPIcp$cfhee4r@|~(l z%)TP$;JaSrsTzdM>|plj%|O?$MO#$T5yQr_O#BEkBqy+qMwO z#PBD=i-LYxir$Z1#SWNdg~28wQDp=ru?zgF!#B#>ov4XfO*Xu-SkDVX)UWm=2U(n` zyi>z^qNOrYJ!;D!hj%QrC4z1}3VCj~@R*ju@U9abUJXsJ{4$2#3%*0I*!3ZKcKi(v z-nw;>sq)jGbYp^@?brJw8M4M-l-vj{&T~f*Kka9w)3kGAv#dNj+M?>d4Bl(P(KW#` zD4@v=G3Hx+yRZ29=*R0fMf|gf)o)odG;P!#_meRpc5fAFq1n4m`J?`X%Y@fV5R?#G z@{)~g8x3DwJ6rA`=@Pqj6ljGr{3{@sv16a60lToE?}}Dmq`vgiY9vYQL8FKP{DVf zj$3r~%G@h2_Md%4$esknEC3=P{>|WpYbJRdgZ^glfI-z!xXhYrv`aBWJjTN`e(zC} zNgQa!7Px1eW*EQQCq(Ayp+&zV0YzgoJn(qf4t#-9N9{EzJ%&9O<=aZX=_T*6yzmst zDlG4^i|F<{{_H{w%(NkmCSx5cZ7jRPYx!*t^_2z64*jiwn~ohc^bx!7L`t9p1iPJ~R&8pP@v zJI0z@nf3BA7U_u~<2qZs>cw5a&Ik}5h5-xxai@b?6_N7}1(KBmJ42YEMy;8Rz6of}CwkIFPX;d4{_UCPc1hO+0 z8W&up9ZlMuUFZes!u0%0Y=e9aQHwB?T5Fa{t3PQeNDSqpX)D7ysIGsL9gq zU9DR=?V{H_ICaY4iv`L$v_^}mX~Oc$MQZ7#H0kChf^@{asxdpVk7nj<3p|C z)(c?g=oxamkTAqrXZ{1-x?8>govF3 z>S}Kch^rR%-QhL&DVQUolYHCG9$=v3-pPK=!a?h?<+Q66n1ziT_&SLVx3+^D39ycI zQ1fPL4Qz?nDQiJY_pm0|!P%pY zsvapC+eqrbXRK|F)P)D9szfpM@`HMcZ=@uRYo51p0&MlKvo>7-?tF>bFre znd_Sgs|L0I*T@7KaV+36Oh<~msgJ|jnm6Uai6_tjv)%cMw~YPiSyK+b6u4^02)}Yh zG#fuC7Ei3cWTu?fw#S0M+5#+-nl&@$hp?+WBBMS>TsSyu%6|Pn@?Ux+LT}mfO{YOs Uvh>m(Wy$r)6E?^5k6pU+U(J1i#sB~S literal 0 HcmV?d00001 From 42441efc4579f30550a1bb19fbe091f82c90c1d2 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Wed, 10 Jan 2024 17:55:57 +0100 Subject: [PATCH 22/22] [rfc] Narrowing to technical scope of ci/cd components Bonus: fixing typos --- rfcs/0000-kuadrant-ci-cd.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/rfcs/0000-kuadrant-ci-cd.md b/rfcs/0000-kuadrant-ci-cd.md index 1b5840a3..9f634658 100644 --- a/rfcs/0000-kuadrant-ci-cd.md +++ b/rfcs/0000-kuadrant-ci-cd.md @@ -1,4 +1,4 @@ -# Kuadrant CI/CD release process +# Kuadrant components CI/CD - Feature Name: `kuadrant-ci-cd` - Start Date: 2023-11-21 @@ -8,7 +8,7 @@ # Summary [summary]: #summary -This RFC not only proposes a new release process for Kuadrant components, but also a new and more agile way of getting +This RFC focuses on how to build and deliver Kuadrant components, in a new and more agile way of getting the desired "artifacts" (images, manifests, etc.) into the hands of the users, devs, QE team and any other process that needs them. @@ -154,7 +154,7 @@ e.g. `0.5.0`, if all is correct, this should push the release to [crates.io](htt ##### After the release 1. Create a `next` branch off `main` -2. Update the _both_ Cargo.toml to point to the next `-dev` release +2. Update _both_ Cargo.toml files to point to the next `-dev` release 3. Create PR 4. Merge to `main` @@ -451,8 +451,8 @@ index 3aebf9d..d17b92b 100644 @@ -1,6 +1,6 @@ [package] name = "limitador" --version = "0.5.0-dev" -+version = "0.5.0" +-version = "0.6.0-dev" ++version = "0.6.0" ``` ```diff diff --git a/limitador-server/Cargo.toml b/limitador-server/Cargo.toml @@ -757,6 +757,7 @@ on Github with the information provided by the user. * change the draft PR on OperatorHub to ready to review. The following steps can be automated by the release workflow, but they could be done manually as well: + 4. Create a `next` branch off `main` 5. Update the _both_ release files to point to the next `-dev` release 6. Create PR @@ -782,6 +783,7 @@ on Github with the information provided by the user. * change the draft PR on OperatorHub to ready to review. The following steps can be automated by the release workflow, but they could be done manually as well: + 4. Create a `next` branch off `main` 5. Update the _both_ release files to point to the next `-dev` release 6. Create PR