New-TestResources.ps1 -TestApplicationId should not be required

[heaths]

Some resources don't use SPs other than to provision (which logging in takes care of), so we should not require the TestApplication* parameters.

[heaths]

Thinking about this more, maybe they are since they pass through to set environment variables. We need to think end-to-end to be sure.

[weshaggard]

If if we do need these in some cases we should either take the SP directly and pull the values or even consider creating the SP on the behalf the users that need one.

[heaths]

Maybe, but this was optimized for CIs that have separate secret variables for tenant, client ID, and client secret. As long as we can log into with those values (should be able to - we are in the script) within the CI and pass the $sp returned variable, that should work.

[pakrym]

Automatic SP creation would make local developer scenarios so much better!

[heaths]

What role should they have in an organization by default? We document a default, but someone knowledgeable in a constrained subscription could figure out what they need. It's questions like that why we left it up to the user and would need to be solved before we start creating SPs on behalf of users.

[pakrym]

What role should they have in an organization by default

Owners of the test resource group, no organization wide permissions.

[weshaggard]

I'll take a look at this while looking at some other clean-up stuff.

[drwill-ms]

The Azure IoT SDK team asks for the ability to run this script without the ProvisionerApplicationId. We need to be able to run this script for our own test environments, and we should be able to run it with our own credentials, rather than create an app Id that has access to our sub.

[heaths]

You can run without the -ProvisionalApplicationId already. There's two parameter sets. Run help new-testresources.ps1 -syntax to see both.

[drwill-ms]

Looks like if I do that, I can't specify my subscription Id?

[heaths]

Pass it when you log in with Connect-AzAccount. That will be the account that is used for provisioning if not otherwise passed to the script.

[drwill-ms]

That works, thanks. Super weird that in one case subscription Id is explicit, and in the other it is inferred.

[heaths]

It's only used for provisioning, and one parameter set is to provide parameters for provisioning instead of relying on the currently logged in user. We use the former parameter set for CIs.