This will likely also mean that we need code to:

1. copy the old config in the place of the new one if it doesn't exist. But print warning if it does
2. 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 🤞

Yeah, not sure how we should handle old configs, but this should definitely be easier to implement and test nowadays 🤞

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? 🤔

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 during k6 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 ⬆️ )

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-run k6 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")
...