Validating Operator bundles

Validating Operator bundles

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.

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.22.0.

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.22.

<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
```