Scorecard - current

operator-sdk scorecard

Overview

The scorecard works by creating all resources required by CRs and the operator.

The scorecard will create another container in the operator deployment which is used to record calls to the API server and run a lot of the tests. The tests performed will also examine some of the fields in the CRs.

The scorecard also supports plugins which allows to extend the functionality of the scorecard and add additional tests on it.

Requirements

Following are some requirements for the operator project which would be checked by the scorecard.

  • Access to a Kubernetes v1.11.3+ cluster

For non-SDK operators:

  • Resource manifests for installing/configuring the operator and custom resources. (see the Writing E2E Tests doc for more information on the global and namespaced manifests)
  • Config getter that supports reading from the KUBECONFIG environment variable (such as the clientcmd or controller-runtime config getters). This is required for the scorecard proxy to work correctly.

NOTE: If you would like to use it to check the integration of your operator project with OLM then also the Cluster Service Version (CSV) file will be required. This is a requirement when the olm-deployed option is used

Running the Scorecard

  1. Setup the .osdk-scorecard.yaml configuration file in your project. See Config file
  2. Create the namespace defined in the RBAC files(role_binding)
  3. Then, run the scorecard command. See the Command args to check its options.

NOTE: If your operator is non-SDK then some steps will be required in order to meet its requirements.

Configuration

The scorecard is configured by a config file that allows configuring internal plugins as well as a few global configuration options.

Config File

To use scorecard, you need to create a config file which by default will be <project_dir>/.osdk-scorecard.yaml.The following is an example of how the config file may look:

  1. scorecard:
  2. # Setting a global scorecard option
  3. output: json
  4. plugins:
  5. # `basic` tests configured to test 2 CRs
  6. - basic:
  7. cr-manifest:
  8. - "deploy/crds/cache.example.com_v1alpha1_memcached_cr.yaml"
  9. - "deploy/crds/cache.example.com_v1alpha1_memcachedrs_cr.yaml"
  10. # `olm` tests configured to test 2 CRs
  11. - olm:
  12. cr-manifest:
  13. - "deploy/crds/cache.example.com_v1alpha1_memcached_cr.yaml"
  14. - "deploy/crds/cache.example.com_v1alpha1_memcachedrs_cr.yaml"
  15. csv-path: "deploy/olm-catalog/memcached-operator/0.0.3/memcached-operator.v0.0.3.clusterserviceversion.yaml"

The hierarchy of config methods for the global options that are also configurable via a flag from highest priority to least is: flag->file->default.

The config file support is provided by the viper package. For more info on how viper configuration works, see viper‘s README.

NOTE: The config file can be in any of the json, yaml, or toml formats as long as the file has the correct extension. As the config file may be extended to allow configuration of all operator-sdk subcommands in the future, the scorecard’s configuration must be under a scorecard subsection.

Command Args

While most configuration is done via a config file, there are a few important args that can be used as follows.

FlagTypeDescription
—bundle, -bstringThe path to a bundle directory used for the bundle validation test.
—configstringPath to config file (default <project_dir>/.osdk-scorecard.yaml; file type and extension must be .yaml). If a config file is not provided and a config file is not found at the default location, the scorecard will exit with an error.
—output, -ostringOutput format. Valid options are: text and json. The default format is text, which is designed to be a simpler human readable format. The json format uses the JSON schema output format used for plugins defined later in this document.
—kubeconfig, -ostringpath to kubeconfig. It sets the kubeconfig internally for internal plugins.
—versionstringThe version of scorecard to run, v1alpha2 is the default, valid values are v1alpha2.
—selector, -lstringThe label selector to filter tests on.
—list, -LboolIf true, only print the test names that would be run based on selector filtering.

Config File Options

OptionTypeDescription
bundlestringequivalent of the —bundle flag. OLM bundle directory path, when specified runs bundle validation
outputstringequivalent of the —output flag. If this option is defined by both the config file and the flag, the flag’s value takes priority
kubeconfigstringequivalent of the —kubeconfig flag. If this option is defined by both the config file and the flag, the flag’s value takes priority
pluginsarraythis is an array of Plugins.

Plugins

A plugin object is used to configure plugins. The possible values for the plugin object are basic, or olm.

Note that each Plugin type has different configuration options and they are named differently in the config. Only one of these fields can be set per plugin.

Basic and OLM

The basic and olm internal plugins have the same configuration fields:

OptionTypeDescription
cr-manifest[]stringpath(s) for CRs being tested.(required if olm-deployed is not set or false)
csv-pathstringpath to CSV for the operator (required for OLM tests or if olm-deployed is set to true)
olm-deployedboolindicates that the CSV and relevant CRD’s have been deployed onto the cluster by the Operator Lifecycle Manager (OLM)
kubeconfigstringpath to kubeconfig. If both the global kubeconfig and this field are set, this field is used for the plugin
namespacestringnamespace to run the plugins in. If not set, the default specified by the kubeconfig is used
init-timeoutinttime in seconds until a timeout during initialization or cleanup of the operator
crds-dirstringpath to directory containing CRDs that must be deployed to the cluster
namespaced-manifeststringmanifest file with all resources that run within a namespace. By default, the scorecard will combine service_account.yaml, role.yaml, role_binding.yaml, and operator.yaml from the deploy directory into a temporary manifest to use as the namespaced manifest
global-manifeststringmanifest containing required resources that run globally (not namespaced). By default, the scorecard will combine all CRDs in the crds-dir directory into a temporary manifest to use as the global manifest
proxy-portintport for scorecard-proxy to listen to, default is port 8889

Tests Performed

Following the description of each internal Plugin. Note that are 8 internal tests across 2 internal plugins that the scorecard can run. If multiple CRs are specified for a plugin, the test environment is fully cleaned up after each CR so each CR gets a clean testing environment.

Each test has a short name that uniquely identifies the test. This is useful for selecting a specific test or tests to run as follows:

  1. operator-sdk scorecard -o text --selector=test=checkspectest
  2. operator-sdk scorecard -o text --selector='test in (checkspectest,checkstatustest)'

Basic Operator

TestDescriptionShort Name
Spec Block ExistsThis test checks the Custom Resource(s) created in the cluster to make sure that all CRs have a spec block. This test has a maximum score of 1checkspectest
Status Block ExistsThis test checks the Custom Resource(s) created in the cluster to make sure that all CRs have a status block. This test has a maximum score of 1checkstatustest
Writing Into CRs Has An EffectThis test reads the scorecard proxy’s logs to verify that the operator is making PUT and/or POST requests to the API server, indicating that it is modifying resources. This test has a maximum score of 1writingintocrshaseffecttest

OLM Integration

TestDescriptionShort Name
OLM Bundle ValidationThis test validates the OLM bundle manifests found in the bundle directory as specifed by the bundle flag. 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 for details on OLM bundles.bundlevalidationtest
Provided APIs have validationThis 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. This test has a maximum score equal to the number of CRs provided via the cr-manifest option.crdshavevalidationtest
Owned CRDs Have Resources ListedThis test makes sure that the CRDs for each CR provided via the cr-manifest option have a resources subsection in the owned CRDs section 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. This test has a maximum score equal to the number of CRs provided via the cr-manifest option.crdshaveresourcestest
Spec Fields With DescriptorsThis test verifies that every field in the Custom Resources’ spec sections have a corresponding descriptor listed in the CSV. This test has a maximum score equal to the total number of fields in the spec sections of each custom resource passed in via the cr-manifest option.specdescriptorstest
Status Fields With DescriptorsThis test verifies that every field in the Custom Resources’ status sections have a corresponding descriptor listed in the CSV. This test has a maximum score equal to the total number of fields in the status sections of each custom resource passed in via the cr-manifest option.statusdescriptorstest

Exit Status

The scorecard return code is 1 if any of the tests executed did not pass and 0 if all selected tests pass.

Extending the Scorecard with Plugins

To allow the scorecard to be further extended and capable of more complex testing as well as allow the community to make their own scorecard tests, a plugin system has been implemented for the scorecard. To use it, a plugin developer simply needs to provide the binary or script, and the user can then configure the scorecard to use the new plugin. Since the scorecard can run any executable as a plugin, the plugins can be written in any programming language supported by the OS the scorecard is being run on. All plugins are run from the root of the operator project.

To provide results to the scorecard, the plugin must output a valid JSON object to its stdout. Invalid JSON in stdout will result in the plugin being marked as errored. To provide logs to the scorecard, plugins can either set the log field for the scorecard suites they return or they can output logs to stderr, which will stream the log to the console if the scorecard is being run in with output unset or set to text, or be added to the main ScorecardOutput.Log field when output is set to json

JSON format

The JSON output is formatted in the same way that a Kubernetes API would be, which allows for updates to the schema as well as the use of various Kubernetes helpers. The Golang structs are defined in pkg/apis/scorecard/v1alpha2/types.go and can be easily implemented by plugins written in Golang. Below is the JSON Schema:

  1. {
  2. "$schema": "http://json-schema.org/draft-04/schema#",
  3. "$ref": "#/definitions/ScorecardOutput",
  4. "definitions": {
  5. "FieldsV1": {
  6. "additionalProperties": false,
  7. "type": "object"
  8. },
  9. "ManagedFieldsEntry": {
  10. "properties": {
  11. "apiVersion": {
  12. "type": "string"
  13. },
  14. "fieldsType": {
  15. "type": "string"
  16. },
  17. "fieldsV1": {
  18. "$schema": "http://json-schema.org/draft-04/schema#",
  19. "$ref": "#/definitions/FieldsV1"
  20. },
  21. "manager": {
  22. "type": "string"
  23. },
  24. "operation": {
  25. "type": "string"
  26. },
  27. "time": {
  28. "$ref": "#/definitions/Time"
  29. }
  30. },
  31. "additionalProperties": false,
  32. "type": "object"
  33. },
  34. "ObjectMeta": {
  35. "properties": {
  36. "annotations": {
  37. "patternProperties": {
  38. ".*": {
  39. "type": "string"
  40. }
  41. },
  42. "type": "object"
  43. },
  44. "clusterName": {
  45. "type": "string"
  46. },
  47. "creationTimestamp": {
  48. "$schema": "http://json-schema.org/draft-04/schema#",
  49. "$ref": "#/definitions/Time"
  50. },
  51. "deletionGracePeriodSeconds": {
  52. "type": "integer"
  53. },
  54. "deletionTimestamp": {
  55. "$ref": "#/definitions/Time"
  56. },
  57. "finalizers": {
  58. "items": {
  59. "type": "string"
  60. },
  61. "type": "array"
  62. },
  63. "generateName": {
  64. "type": "string"
  65. },
  66. "generation": {
  67. "type": "integer"
  68. },
  69. "labels": {
  70. "patternProperties": {
  71. ".*": {
  72. "type": "string"
  73. }
  74. },
  75. "type": "object"
  76. },
  77. "managedFields": {
  78. "items": {
  79. "$schema": "http://json-schema.org/draft-04/schema#",
  80. "$ref": "#/definitions/ManagedFieldsEntry"
  81. },
  82. "type": "array"
  83. },
  84. "name": {
  85. "type": "string"
  86. },
  87. "namespace": {
  88. "type": "string"
  89. },
  90. "ownerReferences": {
  91. "items": {
  92. "$schema": "http://json-schema.org/draft-04/schema#",
  93. "$ref": "#/definitions/OwnerReference"
  94. },
  95. "type": "array"
  96. },
  97. "resourceVersion": {
  98. "type": "string"
  99. },
  100. "selfLink": {
  101. "type": "string"
  102. },
  103. "uid": {
  104. "type": "string"
  105. }
  106. },
  107. "additionalProperties": false,
  108. "type": "object"
  109. },
  110. "OwnerReference": {
  111. "required": [
  112. "apiVersion",
  113. "kind",
  114. "name",
  115. "uid"
  116. ],
  117. "properties": {
  118. "apiVersion": {
  119. "type": "string"
  120. },
  121. "blockOwnerDeletion": {
  122. "type": "boolean"
  123. },
  124. "controller": {
  125. "type": "boolean"
  126. },
  127. "kind": {
  128. "type": "string"
  129. },
  130. "name": {
  131. "type": "string"
  132. },
  133. "uid": {
  134. "type": "string"
  135. }
  136. },
  137. "additionalProperties": false,
  138. "type": "object"
  139. },
  140. "ScorecardOutput": {
  141. "required": [
  142. "TypeMeta",
  143. "log",
  144. "results"
  145. ],
  146. "properties": {
  147. "TypeMeta": {
  148. "$schema": "http://json-schema.org/draft-04/schema#",
  149. "$ref": "#/definitions/TypeMeta"
  150. },
  151. "log": {
  152. "type": "string"
  153. },
  154. "metadata": {
  155. "$schema": "http://json-schema.org/draft-04/schema#",
  156. "$ref": "#/definitions/ObjectMeta"
  157. },
  158. "results": {
  159. "items": {
  160. "$schema": "http://json-schema.org/draft-04/schema#",
  161. "$ref": "#/definitions/ScorecardTestResult"
  162. },
  163. "type": "array"
  164. }
  165. },
  166. "additionalProperties": false,
  167. "type": "object"
  168. },
  169. "ScorecardTestResult": {
  170. "required": [
  171. "name",
  172. "description"
  173. ],
  174. "properties": {
  175. "description": {
  176. "type": "string"
  177. },
  178. "errors": {
  179. "items": {
  180. "type": "string"
  181. },
  182. "type": "array"
  183. },
  184. "labels": {
  185. "patternProperties": {
  186. ".*": {
  187. "type": "string"
  188. }
  189. },
  190. "type": "object"
  191. },
  192. "log": {
  193. "type": "string"
  194. },
  195. "name": {
  196. "type": "string"
  197. },
  198. "state": {
  199. "type": "string"
  200. },
  201. "suggestions": {
  202. "items": {
  203. "type": "string"
  204. },
  205. "type": "array"
  206. }
  207. },
  208. "additionalProperties": false,
  209. "type": "object"
  210. },
  211. "Time": {
  212. "additionalProperties": false,
  213. "type": "object"
  214. },
  215. "TypeMeta": {
  216. "properties": {
  217. "apiVersion": {
  218. "type": "string"
  219. },
  220. "kind": {
  221. "type": "string"
  222. }
  223. },
  224. "additionalProperties": false,
  225. "type": "object"
  226. }
  227. }
  228. }

NOTE: The ScorecardOutput object is designed the same as a Kubernetes API, and thus also has a full TypeMeta and ObjectMeta. This means that it contains various other fields such as selfLink, uid, and others. At the moment, the only required fields and the only fields that will be checked by the scorecard are the kind and apiVersion fields as listed in the above JSONSchema.

Example of a valid JSON output:

  1. {
  2. "kind": "ScorecardOutput",
  3. "apiVersion": "osdk.openshift.io/v1alpha2",
  4. "metadata": {
  5. "creationTimestamp": null
  6. },
  7. "log": "time=\"2020-01-16T15:30:41-06:00\" level=info msg=\"Using config file: /home/someuser/projects/memcached-operator/.osdk-scorecard.yaml\"\n",
  8. "results": [
  9. {
  10. "name": "Spec Block Exists",
  11. "description": "Custom Resource has a Spec Block",
  12. "labels": {
  13. "necessity": "required",
  14. "suite": "basic",
  15. "test": "checkspectest"
  16. },
  17. "state": "pass"
  18. },
  19. {
  20. "name": "Status Block Exists",
  21. "description": "Custom Resource has a Status Block",
  22. "labels": {
  23. "necessity": "required",
  24. "suite": "basic",
  25. "test": "checkstatustest"
  26. },
  27. "state": "pass"
  28. },
  29. {
  30. "name": "Writing into CRs has an effect",
  31. "description": "A CR sends PUT/POST requests to the API server to modify resources in response to spec block changes",
  32. "labels": {
  33. "necessity": "required",
  34. "suite": "basic",
  35. "test": "writingintocrshaseffecttest"
  36. },
  37. "state": "pass"
  38. },
  39. {
  40. "name": "Bundle Validation Test",
  41. "description": "Validates bundle contents",
  42. "labels": {
  43. "necessity": "required",
  44. "suite": "olm",
  45. "test": "bundlevalidationtest"
  46. },
  47. "state": "fail",
  48. "errors": [
  49. "unable to find the OLM 'bundle' directory which is required for this test"
  50. ]
  51. },
  52. {
  53. "name": "Provided APIs have validation",
  54. "description": "All CRDs have an OpenAPI validation subsection",
  55. "labels": {
  56. "necessity": "required",
  57. "suite": "olm",
  58. "test": "crdshavevalidationtest"
  59. },
  60. "state": "pass"
  61. },
  62. {
  63. "name": "Owned CRDs have resources listed",
  64. "description": "All Owned CRDs contain a resources subsection",
  65. "labels": {
  66. "necessity": "required",
  67. "suite": "olm",
  68. "test": "crdshaveresourcestest"
  69. },
  70. "state": "fail",
  71. "suggestions": [
  72. "If it would be helpful to an end-user to understand or troubleshoot your CR, consider adding resources [memcacheds/v1alpha1 replicasets/v1 deployments/v1 services/v1 servicemonitors/v1 pods/v1 configmaps/v1] to the resources section for owned CRD Memcached"
  73. ]
  74. },
  75. {
  76. "name": "Spec fields with descriptors",
  77. "description": "All spec fields have matching descriptors in the CSV",
  78. "labels": {
  79. "necessity": "required",
  80. "suite": "olm",
  81. "test": "specdescriptorstest"
  82. },
  83. "state": "fail",
  84. "suggestions": [
  85. "Add a spec descriptor for size"
  86. ]
  87. },
  88. {
  89. "name": "Status fields with descriptors",
  90. "description": "All status fields have matching descriptors in the CSV",
  91. "labels": {
  92. "necessity": "required",
  93. "suite": "olm",
  94. "test": "statusdescriptorstest"
  95. },
  96. "state": "fail",
  97. "suggestions": [
  98. "Add a status descriptor for status"
  99. ]
  100. }
  101. ]
  102. }

NOTE: The ScorecardOutput.Log field is only intended to be used to log the scorecard’s output and the scorecard will ignore that field if a plugin provides it. To add logs to the main ScorecardOuput.Log field, a plugin can output the logs to stderr.

Running the scorecard with an OLM-managed operator

The scorecard can be run using a Cluster Service Version (CSV), providing a way to test cluster-ready and non-SDK operators.

Running with a CSV alone requires both the csv-path: <CSV manifest path> and olm-deployed options to be set. The scorecard assumes your CSV and relevant CRD’s have been deployed onto the cluster using OLM when using olm-deployed.

The scorecard requires a proxy container in the operator’s Deployment pod to read operator logs. A few modifications to your CSV and creation of one extra object are required to run the proxy before deploying your operator with OLM:

  1. Create a proxy server secret containing a local Kubeconfig:

    1. Generate a username using the scorecard proxy’s namespaced owner reference.

      1. # Substitute "$your_namespace" for the namespace your operator will be deployed in (if any).
      2. $ echo '{"apiVersion":"","kind":"","name":"scorecard","uid":"","Namespace":"'${your_namespace}'"}' | base64 -w 0
      3. eyJhcGlWZXJzaW9uIjoiIiwia2luZCI6IiIsIm5hbWUiOiJzY29yZWNhcmQiLCJ1aWQiOiIiLCJOYW1lc3BhY2UiOiJvbG0ifQo=
    2. Write a Config manifest scorecard-config.yaml using the following template, substituting ${your_username} for the base64 username generated above:

      1. apiVersion: v1
      2. kind: Config
      3. clusters:
      4. - cluster:
      5. insecure-skip-tls-verify: true
      6. server: http://${your_username}@localhost:8889
      7. name: proxy-server
      8. contexts:
      9. - context:
      10. cluster: proxy-server
      11. user: admin/proxy-server
      12. name: $namespace/proxy-server
      13. current-context: $namespace/proxy-server
      14. preferences: {}
      15. users:
      16. - name: admin/proxy-server
      17. user:
      18. username: ${your_username}
      19. password: unused
    3. Encode the Config as base64:

      1. $ cat scorecard-config.yaml | base64 -w 0
      2. YXBpVmVyc2lvbjogdjEKa2luZDogQ29uZmlnCmNsdXN0ZXJzOgotIGNsdXN0ZXI6CiAgICBpbnNlY3VyZS1za2lwLXRscy12ZXJpZnk6IHRydWUKICAgIHNlcnZlcjogaHR0cDovL2V5SmhjR2xXWlhKemFXOXVJam9pSWl3aWEybHVaQ0k2SWlJc0ltNWhiV1VpT2lKelkyOXlaV05oY21RaUxDSjFhV1FpT2lJaUxDSk9ZVzFsYzNCaFkyVWlPaUp2YkcwaWZRbz1AbG9jYWxob3N0Ojg4ODkKICBuYW1lOiBwcm94eS1zZXJ2ZXIKY29udGV4dHM6Ci0gY29udGV4dDoKICAgIGNsdXN0ZXI6IHByb3h5LXNlcnZlcgogICAgdXNlcjogYWRtaW4vcHJveHktc2VydmVyCiAgbmFtZTogL3Byb3h5LXNlcnZlcgpjdXJyZW50LWNvbnRleHQ6IC9wcm94eS1zZXJ2ZXIKcHJlZmVyZW5jZXM6IHt9CnVzZXJzOgotIG5hbWU6IGFkbWluL3Byb3h5LXNlcnZlcgogIHVzZXI6CiAgICB1c2VybmFtZTogZXlKaGNHbFdaWEp6YVc5dUlqb2lJaXdpYTJsdVpDSTZJaUlzSW01aGJXVWlPaUp6WTI5eVpXTmhjbVFpTENKMWFXUWlPaUlpTENKT1lXMWxjM0JoWTJVaU9pSnZiRzBpZlFvPQogICAgcGFzc3dvcmQ6IHVudXNlZAo=
    4. Create a Secret manifest scorecard-secret.yaml containing the operator’s namespace (if any) the Config‘s base64 encoding as a spec.data value under the key kubeconfig:

      1. apiVersion: v1
      2. kind: Secret
      3. metadata:
      4. name: scorecard-kubeconfig
      5. namespace: ${your_namespace}
      6. data:
      7. kubeconfig: ${kubeconfig_base64}
    5. Apply the secret in-cluster:

      1. $ kubectl apply -f scorecard-secret.yaml
    6. Insert a volume referring to the Secret into the operator’s Deployment:

      1. spec:
      2. install:
      3. spec:
      4. deployments:
      5. - name: memcached-operator
      6. spec:
      7. ...
      8. template:
      9. ...
      10. spec:
      11. containers:
      12. ...
      13. volumes:
      14. # scorecard kubeconfig volume
      15. - name: scorecard-kubeconfig
      16. secret:
      17. secretName: scorecard-kubeconfig
      18. items:
      19. - key: kubeconfig
      20. path: config
  2. Insert a volume mount and KUBECONFIG environment variable into each container in your operator’s Deployment:

    1. spec:
    2. install:
    3. spec:
    4. deployments:
    5. - name: memcached-operator
    6. spec:
    7. ...
    8. template:
    9. ...
    10. spec:
    11. containers:
    12. - name: container1
    13. ...
    14. volumeMounts:
    15. # scorecard kubeconfig volume mount
    16. - name: scorecard-kubeconfig
    17. mountPath: /scorecard-secret
    18. env:
    19. # scorecard kubeconfig env
    20. - name: KUBECONFIG
    21. value: /scorecard-secret/config
    22. - name: container2
    23. # Do the same for this and all other containers.
    24. ...
  3. Insert the scorecard proxy container into the operator’s Deployment:

    1. spec:
    2. install:
    3. spec:
    4. deployments:
    5. - name: memcached-operator
    6. spec:
    7. ...
    8. template:
    9. ...
    10. spec:
    11. containers:
    12. ...
    13. # scorecard proxy container
    14. - name: scorecard-proxy
    15. command:
    16. - scorecard-proxy
    17. env:
    18. - name: WATCH_NAMESPACE
    19. valueFrom:
    20. fieldRef:
    21. apiVersion: v1
    22. fieldPath: metadata.namespace
    23. image: quay.io/operator-framework/scorecard-proxy:master
    24. imagePullPolicy: Always
    25. ports:
    26. - name: proxy
    27. containerPort: 8889

Alternatively, the community-operators repo has several bash functions that can perform these operations for you:

  1. $ curl -Lo csv-manifest-modifiers.sh https://raw.githubusercontent.com/operator-framework/community-operators/master/scripts/lib/file
  2. $ . ./csv-manifest-modifiers.sh
  3. # $NAMESPACE is the namespace your operator will deploy in
  4. $ create_kubeconfig_secret_file scorecard-secret.yaml "$NAMESPACE"
  5. $ kubectl apply -f scorecard-secret.yaml
  6. # $CSV_FILE is the path to your operator's CSV manifest
  7. $ insert_kubeconfig_volume "$CSV_FILE"
  8. $ insert_kubeconfig_secret_mount "$CSV_FILE"
  9. $ insert_proxy_container "$CSV_FILE" "quay.io/operator-framework/scorecard-proxy:master"

Once done, follow the steps in this document to bundle your CSV and CRD’s, deploy OLM on minikube or OKD, and deploy your operator. Once these steps have been completed, run the scorecard with both the csv-path: <CSV manifest path> and olm-deployed options set.

NOTES:

  • As of now, using the scorecard with a CSV does not permit multiple CR manifests to be set through the CLI/config/CSV annotations. You will have to tear down your operator in the cluster, re-deploy, and re-run the scorecard for each CR being tested. In the future the scorecard will fully support testing multiple CR’s without requiring users to teardown/standup each time.
  • You can either set cr-manifest or your CSV’s metadata.annotations['alm-examples'] to provide CR’s to the scorecard, but not both.

Last modified June 16, 2020: Switch over to new CLI and deprecate `operator-sdk new —type=go` (#3190) (e128b9e5)