Azure / Azure/azure-rest-api-specs

[TypeSpecRequirement] Stable versions in main should only count as brownfield if no stable suppressions

Open
#29,203 1 comment 0 reactions 1 assignee Claimed by @mikeharder View on GitHub
Central-EngSys Spec PR Tools
Dominant language
TypeSpec
Stars
3.1k
Forks
6k
Avg merge
2d 22h
Merged PRs (30d)
444

Description

The check currently uses the following algo:

1. If your spec is TypeSpec, you are good
2. Else, you need some reason
1. A suppression for exactly this version in suppressions.yaml
2. A "stable" in main, which was intended to mean you shipped a stable version before TypeSpec was required

The problem is step 2.ii. is no longer true, since the version might have been suppressed. Ideally, we would check each version in main, against suppressions.yaml in main, but this would be very expensive. As a proxy, I think we can check if the **current branch** contains **any** suppressions for TSR for **any** stable versions. New algo:

1. If your spec is TypeSpec, you are good
2. Else, you need some reason
1. A suppression for exactly this version in suppressions.yaml
2. A "stable" in main, that is not suppressed, which means it existed before TypeSpec was required and is a permanent exemption
1. We don't want to pull main or check all the folders under stable. As a proxy, we will check if there are **any** suppressions for **any** stable folders in the current spec.

Put another way (I believe is at least mostly equivalent):

* A spec is **greenfield** if it has no `stable` versions in main, or has at least one `stable` TSR suppression
* A spec is **brownfield** if it has a `stable` version in main, and no `stable` TSR suppressions

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.