-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify New-TestResources usage #1077
Simplify New-TestResources usage #1077
Conversation
cc @jsquire, you might like it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need to regenerate the .md file as well for the cmdlet.
Connect-AzAccount -Subscription $defaultSubscription | ||
} | ||
|
||
# If no test application id is specified create a new service principal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oooohhhh.... nice!
# If no test application id is specified create a new service principal | ||
if (!$TestApplicationId) { | ||
Log "TestApplicationId was not specified, creating a new service principal." | ||
$servicePrincipal = New-AzADServicePrincipal -Role Owner |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does that need to be removed at the end of the run, if it was dynamic? (or is it already and I'm just overlooking?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, in theory, you are right. But we never told anyone to remove their service principals after manual creation so I decided to postpone fixing the removing part.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any downside to removing it at the end of the script?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, tests won't run because they won't be able to sign in :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could only remove it in the Remove-TestResources
script, assuming the same principal is used to run the tests (by default they are). You could save that to an environment variable or some other means to know which to remove.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Filed #1078
Co-authored-by: Heath Stewart <heaths@outlook.com>
@@ -119,6 +119,8 @@ $root = [System.IO.Path]::Combine($repositoryRoot, "sdk", $ServiceDirectory) | R | |||
$templateFileName = 'test-resources.json' | |||
$templateFiles = @() | |||
$environmentVariables = @{} | |||
# Azure SDK Developer Playground | |||
$defaultSubscription = "faa080af-c1d8-40ad-9cce-e1a450ca5b57" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this work for partner teams?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we were giving them access. If not they can log in using Connect-AzAccount
on their own.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mitchdenny @weshaggard do you happen to know if partner teams will have access to Azure SDK Dev Playground subscription?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on the current permissions set I believe that its just ADP. Generally folks have contributor access for our org and then a few folks have ownership.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with defaulting to this subscription but can we please test the failure case for someone that doesn't have access to this default sub (or another test sub)? I want to make sure it is pretty clear what is going wrong and not failing in some very hard to diagnose way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it fails with pretty clear access denied message.
cc @drwill-ms, did you have any other pain points with the script? |
[ValidatePattern('^[-a-zA-Z0-9\.\(\)_]{0,80}(?<=[a-zA-Z0-9\(\)])$')] | ||
[string] $BaseName, | ||
|
||
[ValidatePattern('^[-\w\._\(\)]+$')] | ||
[string] $ResourceGroupName, | ||
|
||
[Parameter(Mandatory = $true)] | ||
[Parameter(Mandatory = $true, Position = 0)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a breaking change. You moved the first unnamed parameter position. Leave them both named.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think it would actually break anyone?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think simplifying the script is worth it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't say. Do you think specifying -ServiceDirectory
is too much to type especially compared to everything they had to type before, whether using the script or az CLI directly?
I suppose, at the very least, both were mandatory before so if they did expect this to be $BaseName
, they'd likely get an error that "sdk/Whatever" doesn't exist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't say. Do you think specifying -ServiceDirectory is too much to type especially compared to everything they had to type before, whether using the script or az CLI directly?
Not too much comparatively, but if we can do even better and it's pretty safe I would like to try.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you know you are introducing a breaking change, make sure you go to the sync PRs that get created on changes in this directory and trigger some of the live test pipelines against them just to make sure that they continue to function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great point @mitchdenny, I'll do that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where are you defaulting the ServiceDirectory? Isn't it needed in order to know which arm template to deploy?
edit: Sorry I miss-read the comments it is still mandatory here so you can ignore my comment about it being required.
However we could consider figuring out a way of setting this based on where the script is executed, but that might be a little magical.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't default the ServiceDirectory only the base name. ServiceDirectory is not the only required parameter and I made it positional as well.
Thanks for the call out, Pavel. It has been a while since I used it, and can't remember at the moment. It works pretty well. I think the main thing was the confusion I had with two parameter sets and figuring out which params applied to which set, and wanting to leave some out for the set I used. |
The following pipelines have been queued for testing: |
-ServiceDirectory 'search' ` | ||
-TestApplicationId $sp.ApplicationId ` | ||
-TestApplicationSecret (ConvertFrom-SecureString $sp.Secret -AsPlainText) | ||
eng\common\TestResources\New-TestResources.ps1 -ServiceDirectory 'search' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since partner teams will not have access to Playground subscription, should we leave the first line with Connect-AzAccount?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or should we prompt them to enter a subscription after the fact?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think is more user friendly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'll add the first line back
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there was a way that we can try to login and only prompt if it failed, I would vote for that.
The following pipelines have been queued for testing: |
# Try detecting repos that support OutFile and defaulting to it | ||
if (!$CI -and !$PSBoundParameters.ContainsKey('OutFile') -and $IsWindows) | ||
{ | ||
# TODO: find a better way to detect the language |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chidozieononiwu is working on some common scripts one of which would give you the language. If you import common.ps1 it will import the language-settings.ps1 which will have $language
defined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mind if I file this as a followup?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that really the heuristic we want anyway? Ideally, eventually every language in any platform can do this. It's just a matter of how. When we three talked about this months ago, one idea was even just to chmod the file, which is all the CLI does on linux anyway. I'd rather we base this on some marker - perhaps a file under /eng, or something more general purpose we can read and getting repo configs, like a .json file that PS can read as an object. Then we don't have to keep updating this script and going through all the process around pushing it down.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/check-enforcer override |
* Simplify Net-TestResources usage * docs and windows check * Update eng/common/TestResources/New-TestResources.ps1 Co-authored-by: Heath Stewart <heaths@outlook.com> * update markdown * make service directory the default parameter * Fix links * Doc change Co-authored-by: Heath Stewart <heaths@outlook.com>
Make the script easy to use locally:
Default to Out-File in .NET repo.
Default to username + servicedirectory as a basepath
Automatically login into
Azure SDK Developer Playground
if not logged inSuppress extra output caused by returning variable locally
Auto-create service principal
Typical usage becomes
eng\common\TestResources\New-TestResources.ps1 search
Fixes #541
Fixes #485