operator-framework / operator-framework/operator-sdk
Consider supporting specification of environment variables for test pods in scorecard config.yaml
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 7.7k
- Forks
- 1.8k
- PR merge metrics
- No merged PRs in 30d
Description
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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing how scorecard reads config.yaml and constructs test pods. Identify the configuration schema and pod-building entry point, then verify that an env mapping from each test definition reaches the pod; done means the documented example works without wrapping the entrypoint, with relevant scorecard tests passing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- devops, testing-qa
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100