Chapter 23. Running the certification suite with Red Hat hosted pipeline If you want to certify your operator with the Red Hat Hosted Pipeline you have to create a pull request for the Red Hat certification repository. Choose this path if you are not interested in receiving comprehensive logs, or are not ready to include the tooling in your own CI/CD workflows. Here's an overview of the process: Figure 23.1. Overview of Red Hat hosted pipeline The process begins by submitting your Operator bundle through a GitHub pull request. Red Hat then runs the certification tests using an in-house OpenShift cluster. This path is similar to Operator bundle certification. You can see the certification test results both as comments on the pull request and within your Red Hat Partner Connect Operator bundle. If all the certification tests are successful, your Operator will be automatically merged and published to the Red Hat Container Catalog and the embedded OperatorHub in OpenShift. Follow the instructions to certify your Operator with Red Hat hosted pipeline: Prerequisites Complete the Product listing available on the Red Hat Partner Connect website. On the Red Hat Partner Connect website, go to Components tab. In the Authorized GitHub user accounts field, enter your GitHub username to the list of authorized GitHub users. If you are using a private container registry, from the OpenShift Object YAML field, click Add , to add a docker config.json secret and click Save . Procedure Note Follow this procedure only if you want to run the Red Hat OpenShift Operator certification on the Red Hat hosted pipeline. 23.1. Forking the repository Log in to GitHub and fork the RedHat OpenShift operators upstream repository. Fork the appropriate repositories from the following table, depending on the Catalogs that you are targeting for distribution: Catalog Upstream Repository Certified Catalog https://github.com/redhat-openshift-ecosystem/certified-operators Clone the forked certified-operators repository. Add the contents of your operator bundle to the operators directory available in your forked repository. If you want to publish your operator bundle in multiple catalogs, you can fork each catalog and complete the certification once for each fork. Additional resources For more information about creating a fork in GitHub, see Fork a repo . 23.2. Adding your operator bundle In the operators directory of your fork, there are a series of subdirectories. 23.2.1. If you have certified this operator before - Find the respective folder for your operator in the operators directory. Place the contents of your operator Bundle in this directory. Note Make sure your package name is consistent with the existing folder name for your operator. 23.2.2. If you are newly certifying this operator - If the newly certifying operator does not have a subdirectory already under the operator's parent directory then you have to create one. Create a new directory under operators. The name of this directory should match your operator's package name. For example, my-operator . In this operators directory, create a new subdirectory with the name of your operator, for example, <my-operator> and create a version directory for example, <V1.0> and place your bundle. These directories are preloaded for operators that have been certified before. Under the version directory, add a manifests folder containing all your OpenShift manifests including your clusterserviceversion.yaml file. Recommended directory structure The following example illustrates the recommended directory structure. Configuration file Description config.yaml In this file include the organization of your operator. It can be certified-operators . For example, organization: certified-operators ci.yaml In this file include your Red Hat Technology Partner Component PID for this operator. For example, cert_project_id: <your component pid> . This file stores all the necessary metadata for a successful certification process. annotations.yaml In this file include an annotation of OpenShift versions, which refers to the range of OpenShift versions . For example, v4.8-v4.10 means versions 4.8 through 4.10. Add this to any existing content. For example, # OpenShift annotations com.redhat.openshift.versions: v4.8-v4.10 . The com.redhat.openshift.versions field, which is part of the metadata in the operator bundle, is used to determine whether an operator is included in the certified catalog for a given OpenShift version. You must use it to indicate one or more versions of OpenShift supported by your operator. Note that the letter 'v' must be used before the version, and spaces are not allowed. The syntax is as follows: A single version indicates that the operator is supported on that version of OpenShift or later. The operator is automatically added to the certified catalog for all subsequent OpenShift releases. A single version preceded by '=' indicates that the operator is supported only on that specific version of OpenShift. For example, using =v4.8 will add the operator to the certified catalog for OpenShift 4.8, but not for later OpenShift releases. A range can be used to indicate support only for OpenShift versions within that range. For example, using v4.8-v4.10 will add the operator to the certified catalog for OpenShift 4.8 through 4.10, but not for OpenShift 4.11 or 4.12. Additional resources For more details, see Managing OpenShift Versions . For more information about building an operator bundle, see Working with bundle images . For an example of an operator bundle, see here . 23.3. Creating a Pull Request The final step is to create a pull request for the targeted upstream repo. Catalog Upstream Repository Certified Catalog https://github.com/redhat-openshift-ecosystem/certified-operators If you want to publish your Operator bundle in multiple catalogs, you can create a pull request for each target catalog. If you are not familiar with creating a pull request in GitHub you can find instructions here . Note The title of your pull request must conform to the following format. operator my-operator (v1.4.8) . It should begin with the word operator followed by your Operator package name, followed by the version number in parenthesis. When you create a pull request it triggers the Red Hat hosted pipeline and provides an update through a pull request comment whenever it has failed or completed. 23.3.1. Guidelines to follow You can re-trigger the Red Hat hosted pipeline by closing and reopening your pull request. You can only have one open pull request at a time for a given Operator version. Once a pull request has been successfully merged it can not be changed. You have to bump the version of your Operator and open a new pull request. You must use the package name of your Operator as the directory name that you created under operators. This package name should match the package annotation in the annotations.yaml file. This package name should also match the prefix of the clusterserviceversion.yaml filename. Your pull requests should only modify files in a single Operator version directory. Do not attempt to combine updates to multiple versions or updates across multiple Operators. The version indicator used to name your version directory should match the version indicator used in the title of the pull request. Image tags are not accepted for running the certification tests, only SHA digest are used. Replace all references to image tags with the corresponding SHA digest.

Commands:
├── operators └── my-operator └── v1.0
├── config.yaml ├── operators └── my-operator ├── v1.4.8 │ ├── manifests │ │ ├── cache.example.com_my-operators.yaml │ │ ├── my-operator-controller-manager-metrics-service_v1_service.yaml │ │ ├── my-operator-manager-config_v1_configmap.yaml │ │ ├── my-operator-metrics-reader_rbac.authorization.k8s.io_v1_clusterrole.yaml │ │ └── my-operator.clusterserviceversion.yaml │ └── metadata │ └── annotations.yaml └── ci.yaml