doc: CSV marker for fixing olm-crds-have-resources-test

website/content/en/docs/advanced-topics/scorecard/scorecard.md

@@ -52,8 +52,8 @@ for an overview of command invocation.
 ## Configuration
 
 The scorecard test execution is driven by a configuration file named `config.yaml`, generated by `make bundle`.  Note that if run `make bundle` that any
-changes you have made to `config.yaml` will be overwritten.  To persist 
-any changes to `config.yaml` you can update the kustomize templates found in the 
+changes you have made to `config.yaml` will be overwritten.  To persist
+any changes to `config.yaml` you can update the kustomize templates found in the
 `config/scorecard` directory.
 The configuration file is located at the following location within your bundle directory (`bundle/` by default):
 ```sh
@@ -114,7 +114,7 @@ $ operator-sdk scorecard <bundle_dir_or_image> [flags]
 
 The scorecard requires a positional argument that holds either the
 on-disk path to your operator bundle or the name of a bundle image.  Note
-that the scorecard does not run your operator but merely uses 
+that the scorecard does not run your operator but merely uses
 the scorecard configuration within the bundle contents to know which tests
 to execute.
 
@@ -180,7 +180,7 @@ The scorecard ships with pre-defined tests that are arranged into suites.
 | --------    | -------- | -------- |
 | Bundle Validation | This test validates the bundle manifests found in the bundle that is passed into scorecard.  If the bundle contents contain errors, then the test result output will include the validator log as well as error messages from the validation library.  See this [document][olm-bundle] for details on bundles.| olm-bundle-validation-test |
 | Provided APIs have validation |This test verifies that the CRDs for the provided CRs contain a validation section and that there is validation for each spec and status field detected in the CR. | olm-crds-have-validation-test |
-| Owned CRDs Have Resources Listed | This test makes sure that the CRDs for each CR provided via the `cr-manifest` option have a `resources` subsection in the [`owned` CRDs section][owned-crds] of the CSV. If the test detects used resources that are not listed in the resources section, it will list them in the suggestions at the end of the test. Users are required to fill out the resources section after initial code generation for this test to pass.  | olm-crds-have-resources-test |
+| Owned CRDs Have Resources Listed | This test makes sure that the CRDs for each CR provided via the `cr-manifest` option have a `resources` subsection in the [`owned` CRDs section][owned-crds] of the CSV. If the test detects used resources that are not listed in the resources section, it will list them in the suggestions at the end of the test. Users are required to fill out the resources section after initial code generation for this test to pass. For Go-based operators, use ClusterServiceVersion [API Markers](/docs/building-operators/golang/references/markers) to add resources. | olm-crds-have-resources-test |
 | Spec Fields With Descriptors | This test verifies that every field in the Custom Resources' spec sections have a corresponding descriptor listed in the CSV.| olm-spec-descriptors-test |
 | Status Fields With Descriptors | This test verifies that every field in the Custom Resources' status sections have a corresponding descriptor listed in the CSV.| olm-status-descriptors-test |
 

website/content/en/docs/building-operators/golang/references/markers.md

@@ -112,7 +112,7 @@ These examples assume `Memcached`, `MemcachedSpec`, and `MemcachedStatus` are th
 	type MemcachedPods struct {
 		// Size is the size of the memcached deployment.
 		//+operator-sdk:csv:customresourcedefinitions:type=spec
-		//+operator-sdk:csv:customresourcedefinitions.type=status
+		//+operator-sdk:csv:customresourcedefinitions:type=status
 		Size int32 `json:"size"`
 	}
 	```