Chapter 22. 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 22.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 previous 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.jsonsecret and click Save.
Procedure
Follow this procedure only if you want to run the Red Hat OpenShift Operator certification on the Red Hat hosted pipeline.
22.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.
22.2. Adding your operator bundle
In the operators directory of your fork, there are a series of subdirectories.
22.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.
Make sure your package name is consistent with the existing folder name for your operator.
22.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.├── operators └── my-operator └── v1.0-
Under the version directory, add a
manifestsfolder containing all your OpenShift manifests including yourclusterserviceversion.yamlfile.
Recommended directory structure
The following example illustrates the recommended directory structure.
├── 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| Configuration file | Description |
|---|---|
| config.yaml |
In this file include the organization of your operator. It can be |
| ci.yaml | In this file include your Red Hat Technology Partner project ID and the organization target for this operator.
For example, |
| annotations.yaml |
In this file include an annotation of OpenShift versions, which refers to the range of OpenShift versions . For example,
For example,
Note that the letter 'v' must be used before the version, and spaces are not allowed. The syntax is as follows:
|
Additional resources
- For more details, see Managing OpenShift Versions.
- For an example of an operator Bundle, see here.
22.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.
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.
22.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.
