Unfortunately not. Because of the configuration complexity of the new executors, or even the new advanced options like
gracefulStop for old executor types, and the possibility to launch multiple scenarios simultaneously, there wasn’t a generic way to add new CLI flags or environment variables to cover all of them. Or we couldn’t think of one that wasn’t overly complicated, anyway. We’ve maintained backwards compatibility with most of the ways you could specify execution options in the old k6 versions via CLI flags or env vars, but we haven’t added any new ones for the new executors or scenarios.
That said, you could easily roll your own, so to speak. By using k6 environment variables, you can specify any data you want via the CLI
--env flag (or an actual environment variable) and access it in the script. The important part is that these
__ENV variables are available when the k6 script’s init context is evaluated for the first time, so they can be used in the exported script
options, and thus, can be used to configure
The simplest way this can be used is to pre-configure various scenarios in your script and then just enable them with
k6 run --env SCENARIOS=scenario_name_1,scenario_name_2 script.js, as I demonstrated here: Execution of new scenarios from CLI
Though there’s nothing stopping you from cramming a whole JSON object in one such variable, and then
JSON.parse()-ing it and exporting whatever it contains as
options.scenarios. Or, with a few lines of code, having a simple syntax like
k6 run --env myRampingArrivalRate=1m:5000,2m:10000 script.js and then parsing this value and constructing the
stages of a
ramping-arrival-rate executor from it.