Consider supporting specification of environment variables for test pods in scorecard config.yaml

[tmckayus]

trafficstars

Feature Request

Allow env vars to be specified for the test pod in config.yaml (because sometimes passing args is not convenient)

Example: I've created a source-to-image (S2I) builder that takes a repository of tests as an input (written to use a version of the openshift commandline test suite) and produces a test image that is compatible with scorecard. The rest runner and the test function library are fixed, but the test repository itself is open-ended.

It would be nice to be able to set environment variables for the test pod in the scorecard config.yaml to control optional features or configure particular tests. The executable invoked by operator-sdk scorecard itself cannot really take these test-specific values as arguments, since the runner is general

The following seems to be a workaround, but it's a little messy and may interfere with a signal handler in PID 1 (still have to test that)

tests:
- name: "customtest1"
  image: quay.io/tmckayus/perceptilabs-test:latest
  entrypoint:
  - bash 
  - -c
  - "export STORAGE_CLASS=sam; scorecard -- -i"
  labels:
    suite: peak

Describe the solution you'd like

I would like to see something like this

tests:
- name: "customtest1"
  image: quay.io/tmckayus/perceptilabs-test:latest
  entrypoint:
  - scorecard
  env:
     STORAGE_CLASS: sam
  labels:
    suite: peak

[estroz]

/ping @shawn-hurley

[kensipe]

I would like to align the results with kuttl as well

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[camilamacedo86]

/lifecycle frozen

HI @estroz @asmacdo,

It is label as a priority. So, should not it be add in a milestone?

[asmacdo]

It still looks like this needs discussion-- I think its classified correctly for now, but because its priority/important-longterm we can discuss in the next grooming meeting, scheduled for January 13. If anyone wants to make a case for an upcoming milestone, feel free to come! https://github.com/operator-framework/community/#operator-sdk-grooming-meeting

[varshaprasad96]

cc: @theishshah

[varshaprasad96]

@theishshah @kensipe could you please let us know if this feature has already been implemented in scorecard, since the issue has been open for a while.