Validating Operator bundles - Developing Operators | Operators

About the bundle validate command
Built-in bundle validate tests
Running the bundle validate command

As an Operator author, you can run the bundle validate command in the Operator SDK to validate the content and format of an Operator bundle. You can run the command on a remote Operator bundle image or a local Operator bundle directory.

The Red Hat-supported version of the Operator SDK CLI tool, including the related scaffolding and testing tools for Operator projects, is deprecated and is planned to be removed in a future release of OpenShift Dedicated. Red Hat will provide bug fixes and support for this feature during the current release lifecycle, but this feature will no longer receive enhancements and will be removed from future OpenShift Dedicated releases.

The Red Hat-supported version of the Operator SDK is not recommended for creating new Operator projects. Operator authors with existing Operator projects can use the version of the Operator SDK CLI tool released with OpenShift Dedicated to maintain their projects and create Operator releases targeting newer versions of OpenShift Dedicated.

The following related base images for Operator projects are not deprecated. The runtime functionality and configuration APIs for these base images are still supported for bug fixes and for addressing CVEs.

The base image for Ansible-based Operator projects
The base image for Helm-based Operator projects

For information about the unsupported, community-maintained, version of the Operator SDK, see Operator SDK (Operator Framework).

About the bundle validate command

While the Operator SDK scorecard command can run tests on your Operator based on a configuration file and test images, the bundle validate subcommand can validate local bundle directories and remote bundle images for content and structure.

bundle validate command syntax

$ operator-sdk bundle validate <bundle_dir_or_image> <flags>

The bundle validate command runs automatically when you build your bundle using the make bundle command.

Bundle images are pulled from a remote registry and built locally before they are validated. Local bundle directories must contain Operator metadata and manifests. The bundle metadata and manifests must have a structure similar to the following bundle layout:

Example bundle layout

./bundle
  ├── manifests
  │   ├── cache.my.domain_memcacheds.yaml
  │   └── memcached-operator.clusterserviceversion.yaml
  └── metadata
      └── annotations.yaml

Bundle tests pass validation and finish with an exit code of 0 if no errors are detected.

Example output

INFO[0000] All validation tests have completed successfully

Tests fail validation and finish with an exit code of 1 if errors are detected.

Example output

ERRO[0000] Error: Value cache.example.com/v1alpha1, Kind=Memcached: CRD "cache.example.com/v1alpha1, Kind=Memcached" is present in bundle "" but not defined in CSV

Bundle tests that result in warnings can still pass validation with an exit code of 0 as long as no errors are detected. Tests only fail on errors.

Example output

WARN[0000] Warning: Value : (memcached-operator.v0.0.1) annotations not found
INFO[0000] All validation tests have completed successfully

For further information about the bundle validate subcommand, run:

$ operator-sdk bundle validate -h

Built-in bundle validate tests

The Operator SDK ships with pre-defined validators arranged into suites. If you run the bundle validate command without specifying a validator, the default test runs. The default test verifies that a bundle adheres to the specifications defined by the Operator Framework community. For more information, see "Bundle format".

You can run optional validators to test for issues such as OperatorHub compatibility or deprecated Kubernetes APIs. Optional validators always run in addition to the default test.

bundle validate command syntax for optional test suites

$ operator-sdk bundle validate <bundle_dir_or_image>
  --select-optional <test_label>

Table 1. Addtional `bundle validate` validators
Name	Description	Label
Operator Framework	This validator tests an Operator bundle against the entire suite of validators provided by the Operator Framework.	`suite=operatorframework`
OperatorHub	This validator tests an Operator bundle for compatibility with OperatorHub.	`name=operatorhub`
Good Practices	This validator tests whether an Operator bundle complies with good practices as defined by the Operator Framework. It checks for issues, such as an empty CRD description or unsupported Operator Lifecycle Manager (OLM) resources.	`name=good-practices`

Additional resources

Bundle format

Running the bundle validate command

The default validator runs a test every time you enter the bundle validate command. You can run optional validators using the --select-optional flag. Optional validators run tests in addition to the default test.

Prerequisites

Operator project generated by using the Operator SDK

Procedure

If you want to run the default validator against a local bundle directory, enter the following command from your Operator project directory:
```
$ operator-sdk bundle validate ./bundle
```

If you want to run the default validator against a remote Operator bundle image, enter the following command:

$ operator-sdk bundle validate \
  <bundle_registry>/<bundle_image_name>:<tag>

where:

<bundle_registry>

Specifies the registry where the bundle is hosted, such as quay.io/example.

<bundle_image_name>

Specifies the name of the bundle image, such as memcached-operator.

<tag>

Specifies the tag of the bundle image, such as v1.36.1.

If you want to validate an Operator bundle image, you must host your image in a remote registry. The Operator SDK pulls the image and builds it locally before running tests. The bundle validate command does not support testing local bundle images.

If you want to run an additional validator against an Operator bundle, enter the following command:
```
$ operator-sdk bundle validate \
  <bundle_dir_or_image> \
  --select-optional <test_label>
```
where:
<bundle_dir_or_image>

Specifies the local bundle directory or remote bundle image, such as ~/projects/memcached or quay.io/example/memcached-operator:v1.36.1.

<test_label>
Specifies the name of the validator you want to run, such as name=good-practices.
Example output

ERRO[0000] Error: Value apiextensions.k8s.io/v1, Kind=CustomResource: unsupported media type registry+v1 for bundle object WARN[0000] Warning: Value k8sevent.v0.0.1: owned CRD "k8sevents.k8s.k8sevent.com" has an empty description