Test resource scripts can be made simplier

[weshaggard]

Instructions at https://github.com/Azure/azure-sdk-tools/tree/master/eng/common/TestResources#on-the-desktop

Having to manually create a service principal and copying bits out of it makes things harder then needed. I think we should get the instructions down to simply:

Connect-AzAccount -Subscription 'YOUR SUBSCRIPTION ID'
eng\common\TestResources\New-TestResources.ps1 'SERVICE DIRECTORY`

We should be able to default the basename based on the logged in user and perhaps appending the service directory so the resource groups can remain separate. We should also be able to set the environment variables in the current shell instead of requiring that someone always sets them in the process. We can of course still dump them to the console for folks that want to set them in another process but I think doing it automatically will save lots of headache for normal use cases.

Of course if we do set the env variables automatically we should also remove them when we call the clean remove script. So we need a way to track all the things to clean-up. Perhaps we can write a file next to the resources.json file that list just the names (no secrets) of the things to clean-up and we can clean those up.

fyi @danieljurek @heaths @pakrym

[heaths]

Please do not remove the $BaseName parameter. If you want to default it, fine:

[Parameter()]
[ValidateNotNullOrEmpty()] # Requires now that it's not mandatory
[string] $BaseName = $env:USER ?? $env:USERNAME

As for setting environment variables, this was intentionally because it doesn't always work. If you run the .ps1 in pwsh, it works fine. If you do it from a shebang script on linux or macOS, it won't because pwsh is the process that is updated and exits after the script. It's an inconsistent behavior. We could do it, but expect confusion when it doesn't work.

Additionally, it's destructive. Close the shell and variables are gone. Persisting environment variables in Windows with setx (installed with Windows) is easy, but on linux (and possibly macOS) it's not straight forward. Different shells have different ways of not only exporting environment variables, but persisting them (e.g. .bashrc, .profile, .csrc, etc.). The point during MQ was to inform the dev what they need to do and have them do it. I did the shell detection script (inspired from docker-machine) to make it easy to copy and paste into their current environment (not process, for reason I stated above) or persist them as appropriate.

If we use a common prefix like AZURE_TEST or something, we wouldn't need to keep track. If we do keep these in a file, though, they should all go into a single file for discovery.

[pakrym]

You can put variable names to cleanup into a well known environment variable :)

[heaths]

That's the current POR now. If we create an SP, we'll set a variable (env var or file) that says we did, and will remove it if possible (if somehow it gets associated with another sub, removing it fails, IIRC).

[drwill-ms]

Having a basename based on my email alias would be nice.