Skip to content
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

Ability to set custom variables? #1101

Closed
gygitlab opened this issue Aug 5, 2019 · 5 comments
Closed

Ability to set custom variables? #1101

gygitlab opened this issue Aug 5, 2019 · 5 comments
Labels

Comments

@gygitlab
Copy link

gygitlab commented Aug 5, 2019

Is there (or can they be) a way to set custom variables in options that can then be referenced in scripts? I'm looking for a way to change what URLs and variables scripts will use based on the config file I load for flexibility. Cheers.

@na--
Copy link
Member

na-- commented Aug 5, 2019

I'm not sure I fully understand your use case, but maybe the k6 environment variables would be a suitable solution?

You can specify them via the CLI like this: k6 run --env MY_HOSTNAME=prod-hostname.com, k6 run --env MY_HOSTNAME=staging-hostname.com. But you can also save them in a file and source it before executing k6, as long as --include-system-env-vars is true (which by default it is for k6 run, but not for k6 cloud or k6 archive).

@gygitlab
Copy link
Author

gygitlab commented Aug 5, 2019

Thanks for the quick response!

So for context I'm moving to k6 from Artillery. The specific functionality I was trying to replicate is their inline variables. This allowed me to have a config file for every environment I wanted to test and change various variables for each while not impacting the scripts. I did notice the environment config option but it was starting to get a little cumbersome as I needed to set quite a few of them (around 10).

I was hoping to find a way to do this succinctly with k6 config files as I already have those created to set the stages, etc... for each environment. Guess for now I'll need to have a separate envvar file and config file per environment.

If it was possible to even set envvars in the config file like other k6 options that would satisfy my use case.

@na--
Copy link
Member

na-- commented Aug 5, 2019

If it was possible to even set envvars in the config file like other k6 options that would satisfy my use case.

Unfortunately it isn't possible, you can only specify k6 options in the .json config file (either the default one or any custom one you specify with -c/--config).

The inability to specify environment variables there is mostly because the environment variables in k6 are a bit more flexible, but that same flexibility offers a pretty easy workaround for your use case. You can use these environment variables to specify your own custom config file, open() that file and JSON.parse() it and then use parts of it to fill the exported script execution and other options (vus, duration, stages, etc.), and other parts as your environment variables. Here's a simple example:

import http from "k6/http";

let myOptions = JSON.parse(open(__ENV.MY_CONFIG_FILE));

export let options = {
    vus: myOptions.myCustomVUs,
    stages: myOptions.stages,
};

export default function () {
    http.get(`https://${myOptions.myEnv.myHostname}/whatever`);
}

Then you can run that script with k6 run --env MY_CONFIG_FILE=production.json, k6 run --env MY_CONFIG_FILE=staging.json, etc. You can mix and match - as you can see, the environment variables are processed before the k6 options, so you can use them to derive the options.

@gygitlab
Copy link
Author

gygitlab commented Aug 5, 2019

Yeah I did have a similar thought. Will give that a try for now and close this.

Would be good to see custom variables supported natively though. Cheers!

@gygitlab gygitlab closed this as completed Aug 5, 2019
@na--
Copy link
Member

na-- commented Aug 5, 2019

We plan to do something like that with the new executors. It will be done either in #1007 or in a follow-up PR, but in essence you'd be able to specify environment variables per executor, so as part of the normal options.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants