-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Improve template to include tests, live resources, recordings etc #11540
Conversation
@@ -20,7 +20,13 @@ | |||
<GenAPIAdditionalParameters>--exclude-attributes-list "$(MSBuildThisFileDirectory)ApiListing.exclude-attributes.txt" $(GenAPIAdditionalParameters)</GenAPIAdditionalParameters> | |||
<GenAPITargetPath>$(_RefSourceOutputPath)$(AssemblyName).$(TargetFramework).cs</GenAPITargetPath> | |||
</PropertyGroup> | |||
<Delete Files="$(GenAPITargetPath)" /> | |||
<ItemGroup> | |||
<!-- Remove all files that don't start with $(AssemblyName) and the current target --> |
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.
Fixes an issue where copying Azure.Template and re-running Export-API leaves the original API listing around and confuses people.
@@ -75,11 +76,11 @@ private static byte[] DeserializeBody(IDictionary<string, string[]> headers, in | |||
{ | |||
if (property.ValueKind == JsonValueKind.Object) | |||
{ | |||
var arrayBufferWriter = new ArrayBufferWriter<byte>(); | |||
using var writer = new Utf8JsonWriter(arrayBufferWriter); | |||
using var memoryStream = new MemoryStream(); |
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.
Don't need to have IVT from lib to tests or manually include ArrayBufferWriter into test project anymore.
cc @timtay-microsoft @drwill-ms Do you remember any snags that you've hit during bootstrapping of the library? |
@pakrym Files we needed to include appear in the root of the csproj, but we don't want them cluttering up the root with our own files, and have someone accidentally edit them. One thing we did was hide them under the same folder as other imports from the props file. However, it would have been nicer if these were included from that props file automatically, and under the same folder.
|
@pakrym Another small thing in porting our existing code into this project was finding out what to remove, things we didn't need. We had lots of nuget package properties that are filled in automatically. It would be nice if the template pulled all the nuget-specific properties and put them in their own property group, with a comment that says these, and only these, should be supplied. |
@pakrym I also found I got build errors until I included these packages. If they are required, perhaps they could be included by the props file by default.
|
@pakrym For a while, I had to include this file to avoid a build error. Once we started having tests that inherited from ClientTestBase, etc. then I got an error when I did include it.
|
Fixed as part of this PR.
Tracked by #11544 |
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.
Very nice!
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.
Should also add a CONTRIBUTING.md file - at least with a section like Key Vault and Search now have that refer back to the TestResources/README.md file.
} | ||
], | ||
"outputs": { | ||
"KEYVAULT_URL": { |
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.
AZURE_KEYVAULT_URL
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.
Why?
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.
Because that's what the guidelines state, and what we're discussing in another bug.
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.
Guidelines are about client libraries not test infrastructure.
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.
We're asking contributors to set environment variables. These scripts aren't just for us. The point is to make PII easy to identify and clean up, rather than spread sprawl them across an environment block to the point someone may miss PII and secrets leak. That's concerning. Grouping them with a common prefix makes them easy to identify and 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.
We should group them but do it in a common place in the New-TestEnvironment script not throughout tens of test-resources.json
files
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 see how that has anything to do with naming them with a common prefix. Yes, a common prefix should be done consistently in all locations as you pointed out in the other issue.
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.
We control how these outputs are turned into environment variables in a New-TestEnvironment
script. With one change there we can make all the environment variables it creates compliant with any rules we want and not require prefixes in templates at all.
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.
And BTW this follows the guidelines for test variables precisely: https://dev.azure.com/azure-sdk/internal/_wiki/wikis/internal.wiki/2/Azure-DevOps-Pipeline-Guidance?anchor=environment-variables
Environment variables should follow the convention of <service>_<variable>. For example, if you are running live tests and need an environment variable for an Event Hubs instance name, the name would be EVENTHUB_NAME. The parts are
Service: EVENTHUB
Variable: NAME
I'll follow up with more doc changes in other PRs. |
No description provided.