-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Description
This PR got labeled with CI-NewRPNamespaceWithoutRPaaS
(correctly):
However, when the ARM reviewer attempted to override using label RPaaSException
, our automation immediately removed the label:

Instead, I believe the expected behavior is to leave label RPaaSException
alone, and to have it override CI-NewRPNamespaceWithoutRPaaS
to unblock the PR. This code looks correct:
azure-rest-api-specs/.github/workflows/src/summarize-checks/labelling.js
Lines 864 to 869 in 2caaf9e
{ | |
precedence: 0, | |
allPrerequisiteLabels: ["NotReadyForARMReview", "CI-NewRPNamespaceWithoutRPaaS"], | |
anyRequiredLabels: ["RPaaSException"], | |
troubleshootingGuide: notReadyForArmReviewReason("CI-NewRPNamespaceWithoutRPaaS"), | |
}, |
However, some other code must be earlier determining that RPaaSException
should be removed.
This run of summarize-checks removed the label:
https://github.com/Azure/azure-rest-api-specs/actions/runs/18144101186/job/51641822826#step:4:74
I think the bug may be related to confusion between the label RPaaSException
, and property rpaasExceptionRequired
in the impact assessment.
ImpactAssessment: {
"suppressionReviewRequired":true,
"rpaasChange":false,
"newRP":true,
"rpaasRPMissing":true,
"rpaasRpNotInPrivateRepo":false,
"resourceManagerRequired":true,
"dataPlaneRequired":false,
"rpaasExceptionRequired":false,
"typeSpecChanged":false,
"isNewApiVersion":true,
"isDraft":false,
"targetBranch":"main"
}