grafana / k6-operator

An operator for running distributed k6 tests.
Apache License 2.0
541 stars 147 forks source link

Initializer fails on --execution-requirements #375

Open YuriiBudnyi opened 4 months ago

YuriiBudnyi commented 4 months ago

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

yorugac commented 4 months ago

Hi @YuriiBudnyi, This looks like the same issue as here: https://github.com/grafana/k6-operator/issues/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: https://github.com/grafana/k6/issues/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 commented 4 months ago

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