Red Hat Summit Red Hat SummitSupportKonsoleEntwicklerDemo startenKontakt

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

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

A flowchart that is a visual representation of running the certification test on Red Hat hosted pipeline
View larger image
A flowchart that is a visual representation of running the certification test on 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 project. 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 Software Pre-certification Checklist available on the Red Hat Partner Connect website.

  • On the Red Hat Partner Connect website, click your Project Name and navigate to the Settings 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.

22.1. Forking the repository
Link kopieren

  1. Log in to GitHub and fork the RedHat OpenShift operators upstream repository.
  2. Fork the appropriate repositories from the following table, depending on the Catalogs that you are targeting for distribution:
Expand
CatalogUpstream Repository

Certified Catalog

https://github.com/redhat-openshift-ecosystem/certified-operators

Red Hat Marketplace

https://github.com/redhat-openshift-ecosystem/redhat-marketplace-operators

  1. Clone the forked certified-operators repository.
  2. 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.

22.2. Adding your operator bundle
Link kopieren

In the operators directory of your fork, there are a series of subdirectories.

22.2.1. If you have certified this operator before -
Link kopieren

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. For Red Hat Marketplace bundles, you have to manually add the suffix “-rhmp” to your package name. Previously, this was done automatically and therefore it does not impact customer upgrades when you change it manually.

22.2.2. If you are newly certifying this operator -
Link kopieren

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
    Copy to Clipboard Toggle word wrap
  • 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. 

├── 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
Copy to Clipboard Toggle word wrap
Expand
Configuration fileDescription

config.yaml

In this file include the organization of your operator. It can be certified-operators or redhat-marketplace. For example,organization: certified-operators

NOTE

If you are targeting your operator for Red Hat Marketplace distribution, you must include the following annotations in your clusterserviceversion.yaml:

marketplace.openshift.io/remote-workflow: https://marketplace.redhat.com/en-us/operators/ {package_name}/pricing?utm_source=openshift_console

marketplace.openshift.io/support-workflow:https://marketplace.redhat.com/en-us/operators/{package_name}/support?utm_source=openshift_console

ci.yaml

In this file include your Red Hat Technology Partner project ID and the organization target for this operator.

For example, cert_project_id: <your partner project id>. 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.

22.3. Creating a Pull Request
Link kopieren

The final step is to create a pull request for the targeted upstream repo.

Expand
CatalogUpstream Repository

Certified Catalog

https://github.com/redhat-openshift-ecosystem/certified-operators

Red Hat Marketplace

https://github.com/redhat-openshift-ecosystem/redhat-marketplace-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.

22.3.1. Guidelines to follow
Link kopieren

  • 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.
Nach oben
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2025 Red Hat