Skip to content
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

Merged

Conversation

pakrym
Copy link
Contributor

@pakrym pakrym commented Oct 6, 2020

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 in
Suppress 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

@pakrym
Copy link
Contributor Author

pakrym commented Oct 6, 2020

cc @jsquire, you might like it

@heaths heaths changed the title Simplify Net-TestResources usage Simplify New-TestResources usage Oct 6, 2020
Copy link
Member

@heaths heaths left a 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.

eng/common/TestResources/New-TestResources.ps1 Outdated Show resolved Hide resolved
Connect-AzAccount -Subscription $defaultSubscription
}

# If no test application id is specified create a new service principal
Copy link
Member

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
Copy link
Member

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

Copy link
Contributor Author

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.

Copy link
Member

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?

Copy link
Contributor Author

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 :)

Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Filed #1078

pakrym and others added 2 commits October 6, 2020 12:54
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"
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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?

Copy link
Contributor

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.

Copy link
Member

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.

Copy link
Contributor Author

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.

@pakrym
Copy link
Contributor Author

pakrym commented Oct 6, 2020

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)]
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Member

@weshaggard weshaggard Oct 8, 2020

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.

Copy link
Contributor Author

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.

@drwill-ms
Copy link

cc @drwill-ms, did you have any other pain points with the script?

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.

@azure-sdk
Copy link
Collaborator

The following pipelines have been queued for testing:
java - template
js - template
net - template
python - template
Sign off on the approval gate to test the release stage of each pipeline.

-ServiceDirectory 'search' `
-TestApplicationId $sp.ApplicationId `
-TestApplicationSecret (ConvertFrom-SecureString $sp.Secret -AsPlainText)
eng\common\TestResources\New-TestResources.ps1 -ServiceDirectory 'search'
Copy link
Member

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?

Copy link
Member

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?

Copy link
Contributor Author

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?

Copy link
Contributor Author

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

Copy link
Member

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.

@azure-sdk
Copy link
Collaborator

The following pipelines have been queued for testing:
java - template
js - template
net - template
python - template
Sign off on the approval gate to test the release stage of each pipeline.

# 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
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chidozieononiwu
Copy link
Member

/check-enforcer override

@chidozieononiwu chidozieononiwu merged commit dada9b0 into Azure:master Oct 8, 2020
benbp pushed a commit that referenced this pull request Dec 1, 2020
* 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>
sima-zhu pushed a commit to sima-zhu/azure-sdk-tools that referenced this pull request Dec 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Test resource scripts can be made simplier New-TestResources.ps1 -TestApplicationId should not be required
9 participants