From c5bf80332ac9fa0f69b09e51d33839f30cd921fc Mon Sep 17 00:00:00 2001 From: Olivier Cazade Date: Fri, 20 Dec 2024 12:34:11 +0000 Subject: [PATCH] Creating konflux documentation --- docs/Konflux.md | 117 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 117 insertions(+) create mode 100644 docs/Konflux.md diff --git a/docs/Konflux.md b/docs/Konflux.md new file mode 100644 index 000000000..bbad149d2 --- /dev/null +++ b/docs/Konflux.md @@ -0,0 +1,117 @@ +# NetObserv Operator Konflux builds + +> [!WARNING] +> This documentation is about the downstream CI/CD used to build and release Network Observability product in Openshift. +> Some of the links here only work with Red Hat vpn. + +## Links + +Usefull links + +[Netobserv konflux console](https://console.redhat.com/application-pipeline/workspaces/ocp-network-observab/applications) + +[Konlfux documentation](https://gitlab.cee.redhat.com/konflux/docs/users) + +[Konflux build task reference](https://github.com/konflux-ci/build-definitions/tree/main/task) contains the definitions of tasks that can be used in konflux pipeline + +[Konflux release configuration](https://gitlab.cee.redhat.com/releng/konflux-release-data) contains release configuration + +[Konflux sample project](https://github.com/konflux-ci/olm-operator-konflux-sample) is a sample project built as an example on how to use konflux + +[Lightspeed operator](https://github.com/openshift/lightspeed-operator/blob/main/.tekton/fbc-v4-15-pull-request.yaml) probably one of the first project to release with konflux + + +## Builds + +Builds are defined in the .tekton/ directory of each project, to ensure pre-merge build and post merge buids are identical and make maintenance easier, pipeline references has been centralized in a dediceted pipeline-ref file. + +### Nudging + +Nudging is the konflux mecanism to create dependencies and update between components. When a component A is nudging a component B, Konflux will automatically create PR to update component A reference in component B. + +FLP, the ebpf-agent, the console plugin and the operator component are nudging the bundle build once finished and the bundle is nudging the FBC build once finished. + +### File Based Catalog + +When using Konflux to release an operator, it is required to use a File Based Catalog image. This imply some changes: +- FBC will not be additive to another one, the released FBC must contain all previous versions +- one FBC version must be built per Openshift version, the base image used will define the targeted Openshift version +- FBC build must be the only component in an application + +### Konflux pull requests + +Konflux will regulary creates new pull request, there are three categories : + +- [Nudging pull request](https://github.com/netobserv/network-observability-operator/pull/969) To upgrade the reference to another component +- [Konflux tasks update](https://github.com/netobserv/network-observability-operator/pull/787) Up to date tasks are required to pass security check during release. Also the migration note sometimes contains instruction to some required actions +- [Dependencies update](https://github.com/netobserv/network-observability-operator/pull/962) Kondlux internally use [https://github.com/renovatebot/renovate](renovate) to automatically create this PR. + +## Deploying + +The FBC image can be added as a CatalogSource + +> apiVersion: operators.coreos.com/v1alpha1 +> kind: CatalogSource +> metadata: +> name: netobserv-konflux +> namespace: openshift-marketplace +> spec: +> displayName: netobserv-konflux +> image: 'quay.io/repository/redhat-user-workloads/ocp-network-observab-tenant/network-observability-operator-fbc:latest' +> publisher: Netobserv team +> sourceType: grpc + +An `ImageDigestMirrorSet` is then required + +> apiVersion: config.openshift.io/v1 +> kind: ImageDigestMirrorSet +> metadata: +> name: netobserv +> spec: +> imageDigestMirrors: +> - mirrors: +> - quay.io/redhat-user-workloads/ocp-network-observab-tenant/network-observability-operator-1-7 +> source: registry.redhat.io/network-observability/network-observability-rhel9-operator +> - mirrors: +> - quay.io/redhat-user-workloads/ocp-network-observab-tenant/flowlogs-pipeline-1-7 +> source: registry.redhat.io/network-observability/network-observability-flowlogs-pipeline-rhel9 +> - mirrors: +> - quay.io/redhat-user-workloads/ocp-network-observab-tenant/netobserv-ebpf-agent-1-7 +> source: registry.redhat.io/network-observability/network-observability-ebpf-agent-rhel9 +> - mirrors: +> - quay.io/redhat-user-workloads/ocp-network-observab-tenant/network-observability-console-plugin-1-7 +> source: registry.redhat.io/network-observability/network-observability-console-plugin-rhel9 +> - mirrors: +> - quay.io/redhat-user-workloads/ocp-network-observab-tenant/network-observability-cli-1-7 +> source: registry.redhat.io/network-observability/network-observability-cli-rhel9 +> - mirrors: +> - quay.io/redhat-user-workloads/ocp-network-observab-tenant/network-observability-operator-bundle-1-7 +> source: registry.redhat.io/network-observability/network-observability-operator-bundle + +## Release + +[Konflux release configuration](https://gitlab.cee.redhat.com/releng/konflux-release-data) define the release process for konflux built projects. + +For new releases two differents directory are important : +- The [ReleasePlanAdmission](https://gitlab.cee.redhat.com/releng/konflux-release-data/-/tree/main/config/stone-prd-rh01.pg1f.p1/product/ReleasePlanAdmission/ocp-network-observab) directory. The `ReleasePlanAdmission` defines the images that are going to be released and the release target. + +- The [ReleasePlan](https://gitlab.cee.redhat.com/releng/konflux-release-data/-/tree/main/tenants-config/cluster/stone-prd-rh01/tenants/ocp-network-observab-tenant?ref_type=heads) directory. The `ReleasePlan` object define which `ReleasePlanAdmission` are going to be part of the release. + +To be able to see release pipeline, a read access to the `rhtap-releng` namespace is required, this access must be requested in the konflux-user slack channel. + +## Branching + +After creating a new release branch, the following steps need to be done: +- create a new konflux component +- create new component inside the new application, one for each image except the FBC +- edit the new component build pipeline to point to the pipeline-ref file +- creating the new `ReleasePlanAdmission` objects, one for staging one for production +- creating the new `ReleasePlan` objects, one for staging, one for production, note that the `auto-release` label in the production file must be false + +Once it is ready to be released, a new `Release` objects needs to be created to trigger the production release pipeline. + +## After release + +After a release, the following steps should be done: +- moving release candidate file in the catalog to the already released directory +- bumping version label inside the different conteiner images