search

Azure / azure-sdk-tools

Tools repository leveraged by the Azure SDK team.
MIT License
111 stars 176 forks source link

[PR Workflow] Use more labels for new TypeSpec identification #7216

Open allenjzhang opened 11 months ago

allenjzhang commented 11 months ago

Currently we lack of insights on the PRs for newly added product and services. I propose we add similar logic to labeller:

  1. new product. This gets added whenever new folders are created under the specification folder in PR. ie. specifications/sphere
  2. new service. This gets added whenever new folders are created:
    • directly under specifications/[product] eg specifications/sphere/Sphere.Management. This is to catch new TypeSpec specs
    • directly under specifications/[product]\data-plane. This is to catch new data-plane swaggers
    • directly under specifications/[product]\resource-manager This is to catch new ARM swaggers

With these labels and in conjunction with TypeSpec, we can easily spot TypeSpec adoption violations for the reviewer and BI later.

allenjzhang commented 11 months ago

@mikekistler FYI.

konrad-jamrozik commented 11 months ago

Note from Allen: double check with Mike H as he is implementing similar gate checks.

konrad-jamrozik commented 11 months ago

This issue possibly would be a good candidate to be done at the same time as:

maririos commented 11 months ago

@ladonnaq to look into this mapping and the one from Service Tree + Release Planner data

maririos commented 11 months ago

With these labels and in conjunction with TypeSpec, we can easily spot TypeSpec adoption violations for the reviewer and BI later.

@konrad-jamrozik do we have any labeling automation to identify when a PR is TypeSpec vs Swagger? Or how do we correlate the new labels with the type of PR?

konrad-jamrozik commented 11 months ago

@maririos

@konrad-jamrozik do we have any labeling automation to identify when a PR is TypeSpec vs Swagger? Or how do we correlate the new labels with the type of PR?

We do not. But I see @ckairen has implemented Get-TypeSpec-Folders.ps1 and there is some work to make it more accurate:

Also openapi-alps appears to have some logic for finding TypeSpec, e.g. typespecValidations.ts / getChangedTypeSpecPackages

Perhaps we could leverage some of the logic I listed.

konrad-jamrozik commented 11 months ago

@allenjzhang I had a chat with @weshaggard and before starting any implementation work on this issue we would first like to explore a design alternative that decouples the ask in this issue from our spec PR automation infrastructure. Looks like this work could be accomplished with a standalone PowerShell script that leverages the git repo contents and history to determine where and when TypeSpec specs have been added. No need to couple it with our existing automation.

konrad-jamrozik commented 11 months ago

Related work:

konrad-jamrozik commented 10 months ago

Filed relevant issue that does a subsets of items required by this work item: