[PR Workflow] Use more labels for new TypeSpec identification

[allenjzhang]

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]

@mikekistler FYI.

[konrad-jamrozik]

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

[konrad-jamrozik]

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

• [Breaking Change][PR Workflow] Use more granular labels for Breaking Changes approvals #6374

[maririos]

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

[maririos]

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]

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

• [TypeSpec Validation] Determine specs to validate by following imports azure-rest-api-specs#25544

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]

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

Related work:

• [PR Workflow] Update REST API PR labeling bot for TypeSpec rename #5917

[konrad-jamrozik]

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

• [PR Workflow] Add TypeSpec label if appropriate files are changed #7353