Workload argument splitting does not respect quotes

[atombender]

Brief summary

When the operator takes the workload arguments, it splits by spaces and does not respect quotes.

k6-operator version or image

0.0.8

K6 YAML

apiVersion: k6.io/v1alpha1
kind: K6
metadata:
  creationTimestamp: "2023-03-30T09:48:06Z"
  generation: 1
  labels:
    k6-workload-id: benchmark-pre-test-328cxme35q2gw
    test-id: pre-test
  name: benchmark-pre-test-328cxme35q2gw
  namespace: k6-tests
  resourceVersion: "104356441"
  uid: f46e0896-b34c-48df-9297-1d8ba9fc8885
spec:
  arguments: --tag=test_id=pre-test -e 'QUERY=*[_type == "collection"][0..10]'
  parallelism: 10
  runner:
    image: eu.gcr.io/sanity-cloud/xk6-sanity
    resources:
      limits:
        cpu: "3"
        memory: 8Gi
      requests:
        cpu: "3"
        memory: 8Gi
    securityContext: {}
    serviceAccountName: k6-test-runner
  script:
    configMap:
      file: test.js
      name: benchmark-pre-test-328cxme35q2gw-script
    volumeClaim:
      name: ""
  scuttle: {}
  starter:
    metadata: {}
    resources: {}
    securityContext: {}
status:
  stage: created

Other environment details (if applicable)

No response

Steps to reproduce the problem

From my spec:

spec:
  arguments: --tag=test_id=pre-test -e 'QUERY=*[_type == "collection"][0..10]'

Expected behaviour

This is the command argument list I expected:

    - -e
    - "QUERY=*[_type == "collection"][0..10]"

Actual behaviour

This is transformed by the operator into the following pod:

spec:
  automountServiceAccountToken: true
  containers:
  - command:
    - k6
    - run
    - --quiet
    - --execution-segment=7/10:8/10
    - --execution-segment-sequence=0,1/10,2/10,3/10,4/10,5/10,6/10,7/10,8/10,9/10,1
    - -e
    - '''QUERY=*[_type'
    - ==
    - '"collection"][0..10]'''
    - /test/test.js
    - --address=0.0.0.0:6565
    - --paused
    - --tag
    - instance_id=8
    - --tag
    - job_name=benchmark-pre-test-328cxme35q2gw-8

Notice how it has broken the -e value into three pieces and ignored the quotes.

[yorugac]

Thanks for opening this @atombender!
I think the workaround in case of env vars could be with using --include-system-env-vars option?
But either way, the parsing of arguments in the k6-operator is rather simple and doesn't cover quotes just as you noted. In addition to env vars, there are other options in k6 that can rely on quotes as well even if they're probably not encountered as much in k6-operator usage, like --block-hostnames or --log-output.

[atombender]

Yes, we use the --include-system-env-vars workaround, but I'd prefer to avoid this to avoid leaking sensitive environment variables.

[yorugac]

It seems I forgot to link it, but there's an issue for this actually:
#162