-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[KeyVault] - Suppress known validation false-positives #18370
Conversation
Hi, @maorleger Thanks for your PR. I am workflow bot for review process. Here are some small tips. Any feedback about review process or workflow bot, pls contact swagger and tools team. [email protected] |
[Call for Action] To better understand Azure service dev/test scenario, and support Azure service developer better on Swagger and REST API related tests in early phase, please help to fill in with this survey https://aka.ms/SurveyForEarlyPhase. It will take 5 to 10 minutes. If you already complete survey, please neglect this comment. Thanks. |
Swagger pipeline restarted successfully, please wait for status update in this comment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could merge this, but I'd prefer it's not limited to just rbac.json. Though, the fact this succeeded makes me wonder if the from
is ignored for this level of validation errors (previously wasn't suppressable).
@@ -429,4 +429,11 @@ directive: | |||
from: securitydomain.json | |||
where: $.definitions.TransferKey.properties.key_format | |||
reason: Consistency with other properties | |||
- suppress: DOUBLE_FORWARD_SLASHES_IN_URL | |||
from: rbac.json |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still, since both of these problems happen in other files, does suppression work if you get rid of from: rbac.json
? Is it required?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK for me. But I didn't find the double slash in rbac.json?
https://github.com/Azure/azure-rest-api-specs/blob/main/specification/keyvault/data-plane/Microsoft.KeyVault/stable/7.3/rbac.json
@jhendrixMSFT / @heaths I'd like to merge this if possible - mind merging this for me? @weidongxu-microsoft - The error comes up because the scope "/" is valid. If you look at the https://github.com/Azure/azure-rest-api-specs/blob/main/specification/keyvault/data-plane/Microsoft.KeyVault/stable/7.2/examples/GetRoleDefinition-example.json#L4 sample for example. The only valid values today are |
MSFT employees can try out our new experience at OpenAPI Hub - one location for using our validation tools and finding your workflow.
There are a few validation errors that came up in #18028 that we would want to suppress, so that future merges can have a clean build.
note to reviewers: This is my first attempt at suppressing these, and am not familiar with the repo guidelines. So, please feel free to let me know if there are better ways to support what we're trying to do. Also please assume this is entirely incorrect 😄 I just did the simplest thing that suppresses these errors when running
oav
locally.The errors that are being suppressed:
/
for the global scope and/keys
for the keys scope. When scope is part of the path parameters in the RBAC case, the resulting URL will have multiple slashes. They are parsed correctly by the service and while may not be ideal, are already in production as of 7.2Changelog
Add a changelog entry for this PR by answering the following questions:
Contribution checklist:
If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist
Otherwise your PR may be subject to ARM review requirements. Complete the following:
Check this box if any of the following apply to the PR so that label "WaitForARMFeedback" will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.
Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.
If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.