Initializer fails on --execution-requirements

[YuriiBudnyi]

Brief summary

Hello Team. We only started to use K6 Operator in our environment. But we have an issue with Initializer, it fails on --execution-requirements if we have in test.js const Users = __ENV.USERS.split(" "); for example. The issue could be fixed if I add --execution-requirements --include-system-env-vars but I don't see possibility of changing Initializer command.

k6-operator version or image

0.0.13

Helm chart version (if applicable)

3.5.0

TestRun / PrivateLoadZone YAML

apiVersion: k6.io/v1alpha1
kind: TestRun
metadata:
  name: test-k6
spec:
  cleanup: post
  initializer:
    envFrom:
      - secretRef:
          name: test-secrets
  parallelism: 1
  runner:
    envFrom:
      - secretRef:
          name: test-secrets
  script:
    configMap:
      file: test.js
      name: load-test
  separate: false

Other environment details (if applicable)

No response

Steps to reproduce the problem

Create test.js file with const Users = __ENV.USERS.split(" ");
export USERS="TEST1 TEST2";
Run k6 inspect --execution-requirements test.js will result in error TypeError: Cannot read property 'split' of undefined or null
Run k6 inspect --execution-requirements --include-system-env-vars test.js result without errors

Expected behaviour

Initializer not fails

Actual behaviour

Initializer fails

[Olha Yevtushenko]

Hi @YuriiBudnyi,
This looks like the same issue as here:
#207
And partially now described in the internal docs:
https://github.com/grafana/k6-operator/blob/main/docs/env-vars.md

As is described, there is a known discrepancy in how different k6 commands behave. It is not happening at the level of k6-operator. Adding --include-system-env-vars to initializer command means introducing potential security issues. IMHO, it'd be ideal to fix these issues at k6 level:
grafana/k6#2744

Closer to your use case, would it work for you to move the logic around Users to setup function instead of init context?

[YuriiBudnyi]

Hello @yorugac,
Thank you very much for your response. For now, we will use the workaround described in internal docs:
const Users = __ENV.USERS ? __ENV.USERS.split(" ") : [];
Thanks for the help