Context

Added .eslintrc.json config and imported the eslint-plugin-azure-sdk to cosmos sdk in azure-sdk-for-js repo.
One of the things the plugin does is -
adding license headers like below to all the relevant files when we run lint:fix.

"lint:fix": "eslint package.json tsconfig.json src test samples --ext .ts --fix"

Issue

Below is a screenshot of the changes in one specific file from the PR Azure/azure-sdk-for-js#5151 that represents abnormal behaviour.

I would expect the Copyright headers to be at the first two lines.
The placement of these headers when a file starts with the JSDoc comments(/** * * */) is a little off.

It would be great if this border-case can be fixed to make the plugin add the headers at the beginning of the file.

Reference

https://github.com/Azure/azure-sdk-for-js/pull/5151/files

cc - @ramya-rao-a @southpolesteve @KarishmaGhiya

I'd like to make the warden.yml file less warden specific and more python generic as such we should just do the normal python build and testing in the yml file and have the specific testing as test cases under doc-warden.

@scbedd do you how difficult that would be?

We need a way to compute the version based on some date-stamp or release id so that we can produce and release packages without needing to bump the version everytime for daily builds.

If you save a README.md file as UTF-8 with BOM then Docwarden blows up because it is picking up the BOM bytes for the # character. Probably a low priority at this point but it would make the tool a bit more resilient.

This repo will be building stuff targeting different languages but we want to be able to have one build that will have all the necessary artifacts together so we need to think about how we want to structure the build pipeline to enable building multiple languages.

I have finished the Java support for APIView. This now needs integration into the tool. I believe the integration simply consists of allowing (and documenting) source jar files to be uploaded, and running a Java application (which I will supply offline) with the appropriate commands.

Integrating this into APIView would save me from having to manually create the json files and upload them, which I would appreciate :-)

Enhance Pipeline Generator so that it can take a a set of variables which are added to the pipeline. For example:

pipeline-generator [other args] --variable foo1=value1 --variable foo2=value2

Similar to GitHub, it would be great to be able to make a thread as complete (so that we know it has been actioned and don't need to worry about it any longer). When in the complete state, it would also be good to be able to revert it back to the standard 'incomplete' state.

Currently constructors and methods display usless { } at teh end of the line, e.g.:

public class IdentityClientOptions : ClientOptions {                                  
        public IdentityClientOptions() {}
}

It would be less busy to display it just like C#'s extern decls:

public class IdentityClientOptions : ClientOptions {                                  
        public IdentityClientOptions();
}

public class ConflictProperties {
    public ConflictProperties();
    public string Id { get; }
    public OperationKind OperationKind { get; }
}

These are immutable yet have a public default ctor.

For more context see comments in Azure/azure-sdk-for-java#3075.

Currently we are cloning and building the DependencyChecker tool from https://github.com/JonathanGiles/DependencyChecker.git, instead we should move that tool into this repo and produce a tools package that we publish and consume as part of our Java builds.

FYI @JonathanGiles @bsiegel @mitchdenny

We don't want to force a content exception for all readme's when they're not even a project!

Just need to constrict the list to only those that are next to a project.

It would be nice to have support for package types, so that they don't need to be represented as 'other'.

We want a tool to review API content and structure in a parallel, easily accessible way. A web app being developed to achieve this is currently hosted here.

Major features to be added:

• Cross-language comparison
• File diffs

There are some assorted assets that were left in the project structure after adoption which may or may not be relevant and/or should be refactored and integrated better into the central repository. For example, the local .gitignore, should be reviewed, patterns generalized, and refactored for inclusion in the root .gitignore file.

This work is scoped to loose assets withing the Service Bus client library and is not intended to cover general code clean-up and refactoring.

Data for the report will be based off of public Github data pulled daily.

• Data should be available for all our monitored repositories
• Alerts should be fired on a per repository basis
• Alerts should be fired at an email alias, not be a personal subscription
  • Option Here

1. Alert on PR Age > 21 days
2. Alert on > 45 active PRs on a repository

Azure/azure-sdk#175 tracks the requirement for client libraries to be able to connect through proxies. Just as it is a common requirement to support it, it is also a common requirement to verify said support. Having proxies that are set up to use auth (digest and basic) would presumably be needed for this.

These tools need a pipeline that generates packages and publishes them to an internal feed

• Notifications

  • Notification Creator -- https://github.com/Azure/azure-sdk-tools/pull/118/files#diff-dfdaa6532a97ec1074052264692cc2b6R40
  • Notification GitHub Subscriber -- https://github.com/Azure/azure-sdk-tools/pull/118/files#diff-dfdaa6532a97ec1074052264692cc2b6R57

• Pipeline Generator (eventually, if we want to automate it)

We decided that ASP.NET Core extension methods should live in a separate namespace change analyzer to allow it.

I've had multiple people ask the below questions, so the documentation should be updated..

1. querying appinsights data (like the base query that has been shared in the existing appinsights)
2. More examples!
   • A tiny bit more detail on what happens when a request hits the pixel-server
   • Given a pixel in a markdown, what data comes out of that?

@danieljurek commented on Fri Jun 14 2019

The notification service configures groups in a nested DevOps Team and syncs contacts listed in the CODEOWNERS file for relevant entries in the directory path of a pipeline's tests.yml file.

Rough procedure:

• Get directory location of pipeline's tests.yml file
• Download CODEOWNERS file
• Look for paths that are some subset of the tests.yml file path
  • For this cut, consider excluding expressions like *.yml and focusing only on paths
• Collect contact information associated with paths matching the above criteria
• Get relevant nested Team entry from DevOps (create if does not exist)
• Add contact entries that are not present, remove contact entries which are present in the nested Team but not present in the collected contact entries from the steps above
  • If a user wants to receive notifications but does not want to to be in the CODEOWNERS file they can add themselves to the top level team (instead of the nested team)

• Generate a new pipeline from each tests.yml file that points to that tests.yml file
• Command line parameter to apply variable group defined by identifier to build
• Scheduler which generates the kickoff schedule deterministically for every pipeline (i.e. schedule time is constant for a given pipeline name never changes)

Storage triggers the following analyzer rules but I think they're false positives:

• AZC0006: The guidelines show you can have optional *ClientOptions for your less important ctors per https://azuresdkspecs.z5.web.core.windows.net/DotNetSpec.html#dotnet-client-ctor-overloads but the rule appears to be more strict by demanding separate overloads

• AZC0007: This is looking for AppendBlobClientOptions instead of BlobClientOptions and firing

You can repro by removing the NoWarns at https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/storage/Directory.Build.props#L19

1. Avoid GetAwaiter().GetResult() prefer EnsureCompleted()
2. Avoid having awaits in if (!isAsync) branches of code.

cc @terrajobst

Azure.AI should be one of the pre-approved Namespaces allowed by the Analyzer.

Couple of options for doing this:

• Using labels and allow filtering
• Using folder and have folders per team or per repo

If a pipeline is deleted the corresponding notification teams are not deleted. We should automatically clean these to keep an upper bound on the number of notification teams in our DevOps.

Create a tool which allows us to fail a build quickly when the version of the packages we are producing have already been burned.

Failing Commit (BOM present): Azure/azure-sdk-for-js@d700ded

Succeeding Commit (BOM Gone): Azure/azure-sdk-for-js@4f8ef55

What's occurring is that the BOM is getting parsed into the HTML such that it looks like BOM# H1 -> which translates into the header containing the byte order mark -> which breaks the regex search.

Need to ensure this BOM doesn't get pulled in.

The pipeline definitions that the pipeline generator creates has the wrong path direction for the YAML file reference which causes errors when opening it in the UX:

We've had instances in the past where PRs targeting a branch that is not master in live tests are refused by the bot. These should follow a mapping like the one at: https://github.com/Azure/azure-sdk-for-python/blob/master/sdk/cosmos/ci.yml#L12

pr:
  branches:
    include:
    - master
    - feature/*
    - hotfix/*
    - release/*
    - restapi*

Because other settings are overridden these changes cannot happen in the tests.yml they must be part of the procedure that creates/updates pipelines.

• Set up the build pipeline for building JS tools, similar to .NET in this repo
• If using rush for build orchestrator, will need some more configs than just the yaml file
• PR dependent on this for checks to pass : #53

• For some reason, I can’t comment on indexers
• Deleting a comment doesn’t remove it from the UI until the page is refreshed
• I’d like the ability to edit comments

cc: @terrajobst

• - Client types should have a protected parameterless ctor for mocking
• - Client methods should be virtual
• - Client methods should have Async suffix for async methods
• - Client methods should take CancellationToken as the last parameter

Our team is finally looking into trying this out. Do you know if the pixel server require us to run our own appinsights service, or if there is a managed option we can use?

cc: @vizhur @rastala @danielsc

May require code changes

ClientOptionsAnalyzer in Azure.ClientSdk.Analyzers is not raising AZC0008 for Azure.Identity, whose IdentityClientOptions doesn't have a ServiceVersion enum.

To be notified of build breaks on scheduled builds a tool should configure existing systems:

Use Azure DevOps API to:

• Create teams to receive notifications (1 team per build pipeline)
• Create notification configurations for scheduled builds (1 notification entry per pipeline, linking to the team)

Other considerations:

• Populate teams with code owners information from GitHub (#52) -- Tracked separately.
  (requires microsoft.com email address in profile)

• Should manually added team members be removed? It is probably the case that they go in the CODEOWNERS file

Uploading azure-core demonstrates the issue - annotation types such as the Immutable type are listed as public unknown Immutable, rather than public @interface Immutable, and they do not list their fields properly either.

For now until a more long term solution can be used like DevOps feeds we are going to use blob feed and tools that the dotnet team uses to publish their daily builds.

Storage has four packages they like to work on in one meta *.sln file. doc-warden thinks there should be a readme next to the meta *.sln. This caused a failure at https://dev.azure.com/azure-sdk/public/_build/results?buildId=30620

Should we be looking for *.csproj files instead of *.slns via get_net_packages instead of get_net_package_roots at https://github.com/Azure/azure-sdk-tools/blob/master/packages/python-packages/doc-warden/warden/enforce_readme_presence.py#L56?

I'm adding an exclusion for now and not blocked by this. Thanks!

For simple scripts like the long path and os checks we should create a yaml template we can import into our pipelines instead of using the sdk-tools.zip file.

cc @mitchdenny @chidozieononiwu

The arrow makes Test2 look indented underneath Test1

Generate DevOps pipelines from tests.yml

We've setup an end-to-end pipeline for the eslint-plugin-azure-sdk package stored within the azure-sdk-tools repo. However at the moment it is publishing to a private Azure Artifacts feed.

After discussing with @arpanlaha and @bterlson it has been decided directly to NPM. Currently the package has the scope @azuresdktools but we need to decide if this is appropriate for publishing to NPM.

Adding @weshaggard since we discussed this already. Right now we can't publish NPM packages to Azure Artifacts feeds and we need to be able to reference this package in the JS builds that people will want to run locally which makes NPM the only remaining workable option - other than waiting for Azure Artifacts to finish rolling out NPM support in public feeds (in progress).

Summary

Some assorted assets are expected to have been left in the project structure after migration which may not be relevant and/or should be refactored for better integration into the central repository. F or example, the local .gitignore, should be reviewed, patterns generalized, and refactored for inclusion in the root .gitignore file.

Scope of Work

• Review and clean the loose assets within the Event Hubs client library area of the central repository, removing or adjusting them as needed to integrate with the new location.

Out of Scope

• This work is scoped to loose assets withing the Event Hubs client library and is not intended to cover general code clean-up and refactoring.

Success Criteria

The assets in the Event Hubs client library area of the central repository are appropriate for the monorepo and not redundant to higher level assets.