-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include system env vars into Initializer job #376
Include system env vars into Initializer job #376
Conversation
Hi @ausias-armesto, thanks for the PR. Could you please describe details of your use case over there first? On the subject of the change itself: ATM, I don't think it's a good idea to hard-code this option to all test runs in k6-operator. I'd suggest to look for a workaround first. If there is no workaround, it'd be good to understand why. |
Hi @yorugac , Thanks for the reply. I totally understand that the change may have impact on other test runs and I didn't consider that. My repo is public and you can have a look: https://github.com/hoprnet/hoprd-test/tree/main/k6 This is the pipeline triggering the tests: https://github.com/hoprnet/hoprnet/blob/master/.github/workflows/load-tests.yaml |
This is definitely related to #375 |
In my prev comment: I meant issue #207 and not #187 🤦 Thanks for sharing details @ausias-armesto! AFAIS at the moment, it should be working fine assuming workloads are part of the image 🤔 What is the error you're getting when you try to run this? |
Hi @yorugac, I've checked again with the current helm chart version Thanks. |
Hi @yorugac This snippet of code would fail.
But if the env variable has a default value like in the following snippet, then it works
Adding the parameter as implemented in the PR would solve the issue as well, but the developer needs to be aware of that restriction. |
@ausias-armesto thanks for the update! const TEST_TYPE= __ENV.TEST_TYPE || "DEFAULT_TEST_TYPE" This way of using env vars repeats very often actually. For instance, it's probably present in all examples in quickpizza. Like a "k6 good practice" thing. Perhaps, it could be pointed out more, esp. in the main docs 🤔 I can also add an additional emphasis on it in k6-operator docs for env vars, but it sounds like it is a proper workaround without having to pass system env vars to the jobs. |
I've just added the emphasis about env var defintion in k6-operator doc. As an additional source of recommendations, we recently published this blog too: https://grafana.com/blog/2024/04/30/organizing-your-grafana-k6-performance-testing-suite-best-practices-to-get-started/ I'm closing this PR after all, as the workaround exists and is basically a standard practice for k6 scripts. Thank you again @ausias-armesto, for looking into the issue! |
As part of my specific deployment, I needed to add the system environment variables into the Initializer Job.