k6
k6 copied to clipboard
Change config directory name from "loadimpact" to "k6"
Feature Description
Looking in my .config
, I happened to notice the loadimpact
directory. Inside that directory, there was a k6
directory, which had a config.json
file with my API key.
Can the loadimpact
part be removed? Users looking for their configs will be much more likely to look for k6. Besides, not everyone will associate k6 with loadimpact. As time goes on, this association will become weaker and weaker, too, as the official business name is now k6.
Suggested Solution (optional)
$XDG_CONFIG_HOME/k6/config.json
For example,
~/.config/loadimpact/k6/config.json
↓
~/.config/k6/config.json
Appropriate default directory locations might be different on Mac and Windows.
This will likely also mean that we need code to:
- copy the old config in the place of the new one if it doesn't exist. But print warning if it does
- delete the old, so we don't print warnings.
Hopefully with the latest changes to the cmd
package this will need less hacks to implement :crossed_fingers:
Yeah, not sure how we should handle old configs, but this should definitely be easier to implement and test nowadays :crossed_fingers:
We should probably look into how other grafana projects handle this, if they have similar config files in .config/grafana
, so we can move ours to .config/grafana/k6
? :thinking:
Personally, I am slightly against automatically moving .config/loadimpact
during a k6 run
command. Instead, I think we should:
- support both
.config/loadimpact
and.config/grafana
duringk6 run
,k6 cloud
, etc., with.config/grafana
being checked for and used first, and.config/loadimpact
emitting a deprecation warning if it ends up being loaded - move the config files when
k6 login
is executed (and explain that in the deprecation warning :arrow_up: )
I realized that the docs will need to be updated in a few places if this change happens:
- [ ] https://k6.io/docs/cloud/integrations/token/#authentication-with-a-config-file
- [ ] https://k6.io/docs/using-k6/options/#config ( or
/docs/using-k6/k6-options/reference#config
)
I would go with .config/k6
As far as I know, in the Grafana world, this pattern doesn't exist. Also, it looks easier to find for k6 users.
+1 to I would go with .config/k6
for the same reasons Daniel mentions.
As for the deprecation warning, it would be good if it included instructions for updating (link to doc if not simple).
Sounds like for users using Grafana Cloud k6 - k6 login
would be the proposed quick way to update. But how would this work for pure OSS users? What would they need to do?
Sounds like for users using Grafana Cloud k6 - k6 login would be the proposed quick way to update. But how would this work for pure OSS users? What would they need to do?
k6 login
should be the unique command that writes the config, right? If k6 run
and k6 cloud
both support the two file paths as Ned suggested then we don't need to differentiate the cases.
When the user runs for the first time with the new version they will see the warning, so they can:
- if they are still using the
influxdb
/cloud
output then they can re-runk6 login
and the config will be migrated otherwise - if they are not using the output anymore then they could drop the config file to not see the warning again
The unique edge case I've found is if they are using a custom config that they want to keep but they are not using the output and they wouldn't log in again. In this case, they should migrate the config manually.
Having the migration on k6 run
and k6 cloud
could be easier but I agree with Ned that having this migration on the main commands is a risk not justified by the benefits (with the assumption in mind that the most used case will be to just log in again).
Also of note is that we do print where the default config
is being loaded from on help
(cut to the important parts
$ k6 --help
...
-c, --config string JSON config file (default "/home/mstoykov/.config/loadimpact/k6/config.json")
...