You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: website/content/en/docs/advanced-topics/scorecard/scorecard.md
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -52,8 +52,8 @@ for an overview of command invocation.
52
52
## Configuration
53
53
54
54
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
55
-
changes you have made to `config.yaml` will be overwritten. To persist
56
-
any changes to `config.yaml` you can update the kustomize templates found in the
55
+
changes you have made to `config.yaml` will be overwritten. To persist
56
+
any changes to `config.yaml` you can update the kustomize templates found in the
57
57
`config/scorecard` directory.
58
58
The configuration file is located at the following location within your bundle directory (`bundle/` by default):
The scorecard requires a positional argument that holds either the
116
116
on-disk path to your operator bundle or the name of a bundle image. Note
117
-
that the scorecard does not run your operator but merely uses
117
+
that the scorecard does not run your operator but merely uses
118
118
the scorecard configuration within the bundle contents to know which tests
119
119
to execute.
120
120
@@ -180,7 +180,7 @@ The scorecard ships with pre-defined tests that are arranged into suites.
180
180
| -------- | -------- | -------- |
181
181
| 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 |
182
182
| 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 |
183
-
| 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 |
183
+
| 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 |
184
184
| 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 |
185
185
| 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 |
0 commit comments