operator-courier gives false positive on yaml files that start with "---

[mlbiam]

No description provided.

[mlbiam]

If a CRD file starts with a "---" its valid YAML but if the yaml is included in a ConfigMap CatalogSource and imported to OCP4 it the container will fail with the error message:

time="2019-04-29T20:10:45Z" level=info msg="loading CRDs" configmap=operator-manifests ns=openshift-operator-lifecycle-manager
Error: yaml: line 2: mapping values are not allowed in this context
Usage:
   [flags]

Flags:
  -c, --configMapName string        name of a configmap
  -n, --configMapNamespace string   namespace of a configmap
  -d, --database string             name of db to output (default "bundles.db")
  -h, --help                        help for this command
  -k, --kubeconfig string           absolute path to kubeconfig file
  -p, --port string                 port number to serve on (default "50051")
  -t, --termination-log string      path to a container termination log file (default "/dev/termination-log")

time="2019-04-29T20:10:45Z" level=panic msg="yaml: line 2: mapping values are not allowed in this context"
panic: (*logrus.Entry) (0x154bde0,0xc420187200)

This leads a catalog source that works from a quay.io applicaiton bundle work with OCP4 but not with Red Hat's certification process.

[kevinrizza]

@mlbiam Are you saying that you are creating a catalogsource from a configmap, and you want the operator-courier to validate that? The operator courier's verify command is intended as a way to verify that the operator will package correctly into an app-registry. It is not intended as a full end to end verification for all possible workflows to get an operator to install with OLM.

[mlbiam]

No, I'm saying that the rules for operator-courier verify isn't consistent with the red hat connect certification test process. When I run operator-courier verify on yaml files that start with a "---" it works fine but the red hat connect certification process generates a configmap for the catalog source instead of the quay.io application bundle. The steps in the red hat connect certification process say to verify using operator-courier verify and when I ran into this issue I was told the right place to open a bug report is here.

[kevinrizza]

No, I'm saying that the rules for operator-courier verify isn't consistent with the red hat connect certification test process. When I run operator-courier verify on yaml files that start with a "---" it works fine but the red hat connect certification process generates a configmap for the catalog source instead of the quay.io application bundle. The steps in the red hat connect certification process say to verify using operator-courier verify and when I ran into this issue I was told the right place to open a bug report is here.

It seems like the issue is that the configmap process is broken then? Not sure what this project should do about that, or how we would resolve it. If the bundle we push to the app-registry works and is valid, I don't really see why the courier should attempt to fail validation.

@dmesser ☝️