-
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
Dev healthcareapis microsoft.healthcare apis 2021 11 01 changes #16108
Dev healthcareapis microsoft.healthcare apis 2021 11 01 changes #16108
Conversation
…2021-06-01-preview to version 2021-11-01
Hi, @dustinburson 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. vsswagger@microsoft.com |
[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 Generation Artifacts
|
Hi, @dustinburson your PR are labelled with WaitForARMFeedback. A notification email will be sent out shortly afterwards to notify ARM review board(armapireview@microsoft.com). |
Why is this change made ? It is recommended to use the common types for the private links to ensure consistency across the azure resources. Refers to: specification/healthcareapis/resource-manager/Microsoft.HealthcareApis/stable/2021-11-01/healthcare-apis.json:471 in cbc165f. [](commit_id = cbc165f, deletion_comment = False) |
The change was made to accommodate our RP validation framework. We have a copy of our swagger deployed with our service that we use to validate incoming properties on our PUT and PATCH requests. This is how we support OAPI018. If we have the referenced types those types can't be validated. We could maintain two versions of the Swagger one with the types self contained and one here with the references but that is undesirable due to the maintenance overhead and additional risk of mistakes when updating and synchronizing the content. It also makes it easier to validate the Swagger with tooling since everything is self contained. The data contracts are identical to the common references you pointed out. |
Cant you copy over the folder structure with the links to your repo ?. In reply to: 926043149 |
Unfortunately that isn't the issue. There are two problems.
|
The reason we ask to use common is also to avoid copy paste errors and to make it easier for the audience\reviewers to read this. Please note that this would come up everytime this comes up for ARM review. I would strongly suggest to update the swagger validation mechanism you use with one that supports these references. Again, that said , as long as you make sure that the resources have been copied exactly from the common , I am ok with signing off from ARM side for this change. In reply to: 926074966 |
Hi, @dustinburson. Your PR has no update for 14 days and it is marked as stale PR. If no further update for over 14 days, the bot will close the PR. If you want to refresh the PR, please remove |
@jianyexi thanks for the example and clarification. I will look at making the necessary changes. |
@jianyexi I have added the xmsidentifers property and addressed the linting error. They are now gone. The Swagger Go Track 2 SDK check now has some failures. These have been showing up intermittently when I have been addressing other issues and appear to be unrelated to the changes. Is this a blocking issue (i.e. will prevent us from completing the PR?) and if so do you know who I can work with to understand where the errors are coming from? |
@jianyexi it appears the addition of the xmsidenitiers while solving the linting errors is now triggering SDK azure-sdk-for-net failures. Please see https://github.com/Azure/azure-rest-api-specs/pull/16108/checks?check_run_id=4885819186
|
…2021-11-01-changes
Hi, @dustinburson. Your PR has no update for 14 days and it is marked as stale PR. If no further update for over 14 days, the bot will close the PR. If you want to refresh the PR, please remove |
…2021-11-01-changes
…is 2021 11 01 changes (#2216) Create to sync Azure/azure-rest-api-specs#16108 [ReCreate this PR](https://github.com/azure-resource-manager-schemas/compare/main...AzureSDKAutomation:sdkAuto/healthcareapis?expand=1)
…e#16108) * Adds base for updating Microsoft.HealthcareApis from version preview/2021-06-01-preview to version 2021-11-01 * Updates readme * Updates API version in new specs and examples * Initial updates for 2021-11-01 version * Fix prettier errors and resolve systemData error * Add missing type definitions * Remove pattern for validating Cors Origin. Regex was found to have DDoS issues. New correct pattern triggeres backwards breaking change alerts. Removing patterns in latest iteration to avoid error. Regexes are validated service side with updated logic already. * Add missing endtime from OperationResult * Revert CorsOriginEntry pattern removal to avoid false positive cross version breaking change * Add definition for Properties property in operation definition that was missing. * Test updating default verison per recommendation * Update services and workspaces to use some provisioning state to remove .NET SDK error * Resolve System.InvalidOperationException: Swagger document contains two or more x-ms-enum extensions with the same name 'ManagedServiceIdentityType' and different values: SystemAssigned,None vs. None,SystemAssigned,UserAssigned,SystemAssigned,UserAssigned * Revert "Resolve System.InvalidOperationException: Swagger document contains two or more x-ms-enum extensions with the same name 'ManagedServiceIdentityType' and different values: SystemAssigned,None vs. None,SystemAssigned,UserAssigned,SystemAssigned,UserAssigned" This reverts commit d44373c. * Resolve System.InvalidOperationException: Swagger document contains two or more x-ms-enum extensions with the same name 'ManagedServiceIdentityType' and different values: SystemAssigned,None vs. None,SystemAssigned,UserAssigned,SystemAssigned,UserAssigned" * Change default back to 2021-01-11 version * Change default version back in 2021-11-01 in anticipation of new release * Revert changes that removed common-type references for local references * Add async headers to patch examples * Add managed identity settings to dicomservices * Add resourceVersionPolicyCOnfiguration to workspaces/fhirservices * Fix prettier errors * Add missing description for resourceTypeOverrides * Add missing "x-ms-identifiers" property for arrays.
Adding new API version for 2021-11-01 stable. This PR is taking the resources added in the 2021-06-01-preview and moving them to a stable version with some minor updates.
Changes include:
MSFT employees can try out our new experience at OpenAPI Hub - one location for using our validation tools and finding your workflow.
Changelog
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 copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits.
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.