Adding the TSI GA api-version (2020-05-15) #9974
Conversation
[Staging] Swagger Validation Report
️✔️ |
|
Azure Pipelines successfully started running 1 pipeline(s). |
azure-sdk-for-go - Release
|
azure-sdk-for-js - Release
|
Azure CLI Extension Generation - Release
No readme.md specification configuration files were found that are associated with the files modified in this pull request, or swagger_to_sdk section in readme.md is not configured
|
azure-sdk-for-python - Release
- Breaking Change detected in SDK
|
azure-sdk-for-java - Release
No readme.md specification configuration files were found that are associated with the files modified in this pull request, or swagger_to_sdk section in readme.md is not configured
|
azure-sdk-for-net - Release
No readme.md specification configuration files were found that are associated with the files modified in this pull request, or swagger_to_sdk section in readme.md is not configured
|
Trenton Generation - Release
No readme.md specification configuration files were found that are associated with the files modified in this pull request, or swagger_to_sdk section in readme.md is not configured
|
| "environmentName": "env1", | ||
| "parameters": { | ||
| "location": "West US", | ||
| "kind": "Gen1", |
There was a problem hiding this comment.
@sandshadow I think this would require some code changes, like adding "Gen1" and "Gen2" to the EnvironmentKind enum.
There was a problem hiding this comment.
Yes, you're right. We also need to discuss with Blair for his switch to GA api-version in Ibiza.
|
Can one of the admins verify this patch? |
openapi-assignment-bot
bot
added
the
WaitForARMFeedback
|
Azure Pipelines successfully started running 1 pipeline(s). |
azure-sdk-for-python-track2 - Release
No readme.md specification configuration files were found that are associated with the files modified in this pull request, or swagger_to_sdk section in readme.md is not configured
|
|
Azure Pipelines successfully started running 1 pipeline(s). |
riserrad
changed the title
|
I'm running the Linter to understand if there are issues with the new stable api-version, and I'm getting those:
The problem, though, is that it seems to have these required operations already. For example, the Gen1EnvironmentResource must have a
"responses": {
"200": {
"description": "The environment definition was successfully retrieved and is in the response. If you are polling for the completion of a provisioning or scale operation, you can check its status via the provisioningState property.",
"schema": {
"$ref": "#/definitions/EnvironmentResource"
}
},
"default": {
"description": "HTTP 404 (Not Found): The subscription, resource group, or environment could not be found.",
"schema": {
"$ref": "#/definitions/CloudError"
}
}
}The same applies to the other errors:
Also, if I Lint the preview api-version which this one was derived from (2018-08-15-preview), it does not show any error. Am I interpreting anything wrong? |
|
This PR should only be merged by the end of next week (July 10th) |
@jianyexi Could you help to see about the linter issue? |
The reason is when shipping a new api-version all the lint violation should be fixed .But if you are updating a existing api-version, the old lint violation will be allowed And I don't know why you defined the resource : |
Both Gen1EnvironmentResource and Gen2EnvironmentResource inherit from EnvironmentResource. Every operation that returns an EnvironmentResource returns either a Gen1EnvironmentResource or a Gen2EnvironmentResource. So those operations implicitly are using these resources. Think of EnvironmentResource as an interface with Gen1EnvironmentResource and Gen2EnvironmentResource as the two implementing classes. The kind discriminator on the EnvironmentResource determines which implementation the response actually returns. If the linters don't recognize this, they need to be revised to handle class hierarchies/interfaces. |
|
Got it, thanks for explanation .Since it's an edge case (As I scanned the whole repo , few RP has suppressed these errors by this reason), I think you can suppress the errors the same as before BTW the suppressing process has changed, you should follow the wiki: |
|
Hi @jianyexi - I have submitted a suppression request last wednesday. Do you have any updates about it? We need this spec merged before the end of this week, as we go GA next monday. If you have any suggestions for us, let us know please. |
I will email you later for the next step |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Good morning, folks! A friendly reminder that we would like this PR to be merged today. |
|
For publishing new API version recommendation is to copy the preview version in first commit so that it's easy to review the changes. |
chiragg4u
added
ARMSignedOff
Thank you for the feedback, @chiragg4u . It's a great point and we will consider it when publishing our new api-version. |
* First draft of the changes * Minor fixes before publishing the PR * Adding 2020-05-15 to readme * Removing examples that are not referenced anywhere * Adding the suppressions * Removing EnvironmentsGetExpandStatus.json * Adding 2020-05-15 in places it was missing in readme.md
* First draft of the changes * Minor fixes before publishing the PR * Adding 2020-05-15 to readme * Removing examples that are not referenced anywhere * Adding the suppressions * Removing EnvironmentsGetExpandStatus.json * Adding 2020-05-15 in places it was missing in readme.md
MSFT employees can try out our new experience at OpenAPI Hub - one location for using our validation tools and finding your workflow.
Contribution checklist:
If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist
Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.
Please follow the link to find more details on API review process.