Testing Operators Built With The Operator SDK and Deployed Through OLM

[kaovilai]

https://docs.ci.openshift.org/how-tos/testing-operator-sdk-operators/

The documentation here is no longer recommended by the Operator Framework team because we are moving off of olmv0 to olmv1. The Operator SDK CLI is also in a state that could be considered deprecated and inactive.

[kaovilai]

We're actively migrating OADP's CI off this page's recommended path and ran into gaps. Here's what I think needs to change, based on practical experience:

Problems with the current docs

1. The "Moving to File-Based Catalog" section recommends operator-sdk run bundle as the replacement for ci-index

The current guidance says:

the owners of the steps using OO_INDEX needs to switch to OO_BUNDLE

This pushes everyone toward operator-sdk run bundle via the optional-operators-ci-operator-sdk-$CLOUD workflows, which depend on the cli-operator-sdk base image. But operator-sdk itself is effectively deprecated/inactive per the Operator Framework team.

2. No documentation for the FBC catalog image alternative

There's a third path that avoids both deprecated ci-index AND operator-sdk: build an FBC catalog image from the bundle using opm render, then use it as OO_INDEX with the original optional-operators-ci-$CLOUD workflows.

This pattern is already in use:

• windows-conf-operator-olmv1 step uses a pre-built FBC image + ClusterCatalog + ClusterExtension
• deploy-konflux-operator uses FBC tags for operator installation
• OADP is implementing this now: openshift/release#79327 + openshift/oadp-operator#2204

3. No OLM v1 / ClusterExtension guidance

The page is entirely OLM v0 (CatalogSource + Subscription). With OLM v1 available as TechPreview in OCP 4.18+ and heading toward GA, there should be guidance for the ClusterCatalog + ClusterExtension install path.

Suggested changes

A. Add "Building an FBC Catalog Image" section

Document how to build an FBC catalog image from a CI bundle using opm render, which can then be used as OO_INDEX with the existing optional-operators-ci-$CLOUD workflows — no operator-sdk needed:

# In the operator repo, add a Dockerfile like build/Dockerfile.catalog:
#   FROM opm → opm render ${BUNDLE_IMG} → validate → serve

# ci-operator config:
operator:
  bundles:
  - as: my-operator-bundle
    dockerfile_path: build/Dockerfile.bundle
    skip_building_index: true
images:
  items:
  - build_args:
    - name: BUNDLE_IMG
      value: my-operator-bundle
    dockerfile_path: build/Dockerfile.catalog
    to: my-operator-catalog

# In tests:
dependencies:
  OO_INDEX: my-operator-catalog    # NOT ci-index
env:
  OO_CHANNEL: stable
  OO_PACKAGE: my-operator
  OO_TARGET_NAMESPACES: '!install'
workflow: optional-operators-ci-aws  # original workflow, not operator-sdk variant

B. Update the deprecation messaging

The "Moving to File-Based Catalog" section should present two migration paths:

1. FBC catalog image (recommended) — build Dockerfile.catalog with opm render, use as OO_INDEX with optional-operators-ci-$CLOUD workflows
2. operator-sdk run bundle (alternative, also being deprecated) — use OO_BUNDLE with optional-operators-ci-operator-sdk-$CLOUD workflows

C. Add OLM v1 section

Document the ClusterExtension install path for teams targeting OCP 4.18+:

• ClusterCatalog CR pointing to FBC image
• ServiceAccount + ClusterRoleBinding
• ClusterExtension CR referencing the catalog
• Reference: windows-conf-operator-olmv1 step as working example

D. Rename/retitle the page

Current title "Testing Operators Built With The Operator SDK and Deployed Through OLM" is misleading since operator-sdk is no longer the recommended tool. Something like "Testing OLM-Deployed Operators in CI" would be more accurate.

Open question: build_args pipeline image resolution

One thing we haven't validated yet: whether ci-operator's build_args resolves a value like my-operator-bundle to the full pipeline imagestream pullspec at build time (needed for opm render to pull the image). If it doesn't, the docs should note the workaround (custom step that resolves the pullspec). We're testing this in openshift/release#79327.

Note

Responses generated with Claude

[openshift-ci]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale