operator-framework / operator-framework/operator-sdk

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

Open
#3,437 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

good first issue help wanted kind/feature lifecycle/frozen needs discussion priority/important-longterm scorecard
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.