I’ve noticed when running some of the PS SDK commands I get the following info message
Configuration file found in home directory, this approach of loading configuration will be deprecated in future releases, please upgrade the CLI and use the new ‘sail sdk init config’ command to create a local configuration file
I noticed that when you do this, it creates a config file in the directory where that command is run. It appears to pull from your yaml file in the home directory, pulling client creds and the API url from whichever environment shows as activeenvironment.
Two things I’m curious about on this
I’m confused on the preferred usage here? If I want to switch environments, which I do often, do I need to run both “sail environment [environment]” as well as sail sdk init config to ensure my powershell config.json has the environment I would like to run commands against?
It seems I can have a config.json generated for my tst environment just fine, but when I try and run that for my production environment (I have 3 in my yaml file), I get this error
2023/10/27 08:34:48 ERRO issue retrieving clientID env=prd
Error: secret not found in keyring
It doesn’t seem like there’s any issue with my yaml file, so what gives?
First things first, please make sure you are updated to the newest version of the CLI.
Next, I would ask that you use the sail env command to configure the environments how you want them, then finish up the environments by adding a PAT token using sail set pat.
There have been several ways the CLI has changed while it’s grown and the main one that drove the 2.0 release was improved handling of the secrets values, the clientID and clientSecret are no longer stored in that YAML configuration file.
Lastly, with all that done you should be able to run the SDK config initialization command. I understand you may have a number of environments, and that can get hectic, I would suggest either running the sail sdk init config with the --env flag representing the environment you want to switch to, or you could create different folders with different config files in each one.
I know this is a little strange given the way Powershell typically works, but SDKs as a whole are usually used in more of a development sense, with .env files representing one environment at a time being the standard.
This was something I have spent a lot of time thinking about and tinkering with to try and get the best experience, but if you have any feedback at all or any suggestions for improvements please do not hesitate to let me know.
You and all the other Ambassadors have been such an amazing source of knowledge and feedback.
Please keep up the amazing work, and let me know if you have any issues or questions about what I outlined above.
You don’t have to, if you want you can just manually remove the PAT sections in the YAML, and then re add the PATs with the command provided in my last post
