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

Improve template to include tests, live resources, recordings etc #11540

Merged
merged 7 commits into from
Apr 23, 2020

Conversation

pakrym
Copy link
Contributor

@pakrym pakrym commented Apr 23, 2020

No description provided.

@@ -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 -->
Copy link
Contributor Author

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();
Copy link
Contributor Author

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.

@pakrym
Copy link
Contributor Author

pakrym commented Apr 23, 2020

cc @timtay-microsoft @drwill-ms

Do you remember any snags that you've hit during bootstrapping of the library?

@drwill-ms
Copy link
Contributor

@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.

  <!-- Common source from Azure.Core -->
  <ItemGroup>
    <Compile Include="$(AzureCoreSharedSources)ArrayBufferWriter.cs">
      <LinkBase>Shared\Azure.Core</LinkBase>
    </Compile>
    <Compile Include="$(AzureCoreSharedSources)ClientDiagnostics.cs">
      <LinkBase>Shared\Azure.Core</LinkBase>
    </Compile>
    <Compile Include="$(AzureCoreSharedSources)ContentTypeUtilities.cs">
      <LinkBase>Shared\Azure.Core</LinkBase>
    </Compile>
    <Compile Include="$(AzureCoreSharedSources)DiagnosticScope.cs">
      <LinkBase>Shared\Azure.Core</LinkBase>
    </Compile>
    <Compile Include="$(AzureCoreSharedSources)DiagnosticScopeFactory.cs">
      <LinkBase>Shared\Azure.Core</LinkBase>
    </Compile>
    <Compile Include="$(AzureCoreSharedSources)HttpMessageSanitizer.cs">
      <LinkBase>Shared\Azure.Core</LinkBase>
    </Compile>
    <Compile Include="$(AzureCoreSharedSources)TaskExtensions.cs">
      <LinkBase>Shared\Azure.Core</LinkBase>
    </Compile>
    <Compile Include="$(AzureCoreSharedSources)OperationHelpers.cs">
      <LinkBase>Shared\Azure.Core</LinkBase>
    </Compile>
    <Compile Include="$(AzureCoreSharedSources)Argument.cs">
      <LinkBase>Shared\Azure.Core</LinkBase>
    </Compile>
  </ItemGroup>

@drwill-ms
Copy link
Contributor

@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.

@drwill-ms
Copy link
Contributor

@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.

  <!-- required by TestFramework.props -->
  <ItemGroup>
    <PackageReference Include="NUnit" />
    <PackageReference Include="NUnit3TestAdapter" />
    <PackageReference Include="Castle.Core" />
  </ItemGroup>

@drwill-ms
Copy link
Contributor

@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.

    <!-- Not sure why we don't get this file with TestFramework.props, but I have to add it to avoid a build error. -->
    <Compile Include="$(RepoRoot)\sdk\core\Azure.Core\src\Shared\ArrayBufferWriter.cs">
      <LinkBase>TestFramework</LinkBase>
    </Compile>

@pakrym
Copy link
Contributor Author

pakrym commented Apr 23, 2020

@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.

@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 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.

Tracked by #11544

Copy link
Member

@tg-msft tg-msft left a comment

Choose a reason for hiding this comment

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

Very nice!

@pakrym
Copy link
Contributor Author

pakrym commented Apr 23, 2020

@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.

Tracked by #9775

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.

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": {
Copy link
Member

Choose a reason for hiding this comment

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

AZURE_KEYVAULT_URL

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why?

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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

@pakrym
Copy link
Contributor Author

pakrym commented Apr 23, 2020

I'll follow up with more doc changes in other PRs.

@pakrym pakrym merged commit cebda74 into Azure:master Apr 23, 2020
@pakrym pakrym deleted the pakrym/improve-template branch April 23, 2020 23:14
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.

4 participants