[FEATURE REQUEST] opm tooling does not allow using local bundleDir

[sugarraysam]

Description

When using opm tooling to interact with bundles, we always need to build an image to use the opm tooling. For example:

• opm alpha bundle validate --tag <bundleImage>
• opm render <bundleImage>

As bundle images simply contain data, there is no need to build an image beforehand to interact with these two commands. As a matter of fact, I have written a workaround using the OPM library: https://github.com/mt-sre/addon-metadata-operator/pull/81

We host local bundle directories and thus have access to all the necessary files.

Example

# Structure of a local directory hosting some bundles
$ tree main
main
├── 1.1.0
│   ├── manifests
│   │   ├── kfdef.apps.kubeflow.org.crd.yml
│   │   └── rhods-operator.1.1.0.clusterserviceversion.yml
│   └── metadata
│       └── annotations.yaml
├── 1.1.1
│   ├── manifests
│   │   ├── kfdef.apps.kubeflow.org.crd.yml
│   │   └── rhods-operator.1.1.1.clusterserviceversion.yml
│   └── metadata
│       └── annotations.yaml
├── 1.1.1-29
│   ├── manifests
│   │   ├── kfdef.apps.kubeflow.org.crd.yml
│   │   └── rhods-operator.1.1.1-29.clusterserviceversion.yml
│   └── metadata
│       └── annotations.yaml

# Expect this command to successfully validate the local `1.1.1-29` bundle
$ opm alpha bundle validate --dir main/1.1.1-29

# Expect this command to successfully render the local `1.1.1` bundle
$ opm render main/1.1.1

Feature request

There might be more commands that could benefit from allowing the input of a <bundleDir> but for building bundles and using file-based catalogs, the two following commands are necessary:

1. Support input of a bundle directory with opm render <bundleDir>
2. Support input of a bundle directory with opm alpha bundle validate <bundleDir>

OPM version

$ opm version
Version: version.Version{OpmVersion:"v1.21.0", GitCommit:"9999f796", BuildDate:"2022-03-03T21:23:12Z", GoOs:"linux", GoArch:"amd64"}

[joelanford]

opm render <bundleDir> is not quite straightforward because one of the FBC fields for a bundle is the .image. There's more discussion about this particular request in https://github.com/operator-framework/operator-registry/issues/817

[joelanford]

Also, validating a bundle directory may not be straightforward either. Consider a bundle validator that checks that the bundle's image is a multi-arch manifest list that contains the architectures that the CSV labels claim to support.

[sugarraysam]

That makes sense. The underlying goal was really to avoid the current workflow which is:

1. build bundle
2. push bundle
3. pull bundle
4. validate bundle

The fact that validation happens at the very end is hurting performance of pipelines quite a bit, and requires 2 network interactions (push + pull) which makes the whole process a lot less reliable. I think the encompassing issue is probably this #933