New rule: verify the parameters defined in the global parameters section #84
Comments
|
Another instance that proves that this should definitely be a linter rule. |
|
And one more PR in the management plane was merged incorrectly Azure/azure-rest-api-specs@bc175db#diff-e895aa4ceab43a039f4baf6e7b2bf7c0R3146 |
* Release ServiceFabric 2017-07-01-preview swagger specification This change introduces applicationType, version, application, and service ARM resources for the ServiceFabric resource provider. * Release ServiceFabric 2017-07-01-preview swagger specification This change introduces applicationType, version, application, and service ARM resources for the ServiceFabric resource provider.
|
Another example: Azure/azure-rest-api-specs#1829 |
|
New example: Azure/azure-rest-api-specs#1860 |
|
Another example of merged PR: |
veronicagg
changed the title
|
Apparently I got bitten by this issue as well in Azure/azure-cli#5086 but luckily @lmazuel is watching out for this. Adding a linter to rule to catch this in the future would be 💯. |
|
@salameer At some point we need to prioritize this, this is really time-consuming... :( |
|
@veronicagg @sarangan12 @mcardosos THis seems to be a rule that benefits our group and it's efficiency can we please prioritize this? |
|
@salameer I've just tagged it with Sprint-113. We haven't been updating rules recently or scheduling any work for them, it'd be good to triage and select which ones we'd like to tackle next and how it prioritizes with other work. |
|
For Heaven's sake, please implement this linter rule. |
|
Seriously, now when I type "validator" in my Chrome bar, it suggest me directly this issue.... |
|
The new Rule XmsParameterLocation has been implemented. Refer PR #149 for details. The dotnet classic open api validator is scheduled for release on Monday, March 19, 2018. The code changes are complete. Refer [PR #150][https://github.com//pull/150] for further details. All the existing errors have already been fixed in the specs repository. Refer PR #2649 for details. There is no pending action items (of course the actual release is pending until 19th) in this issue. Resolving it now. |
Autorest treats the parameters defined in the global parameters section as client properties. Hence one needs to be super sure when they are adding a parameter over there.
90% scenario is that subscriptionId and api-version are parameters that should be defined in the lobal parameters section.
However, one can define a parameter that is being referenced in multiple operations (example: resourceGroupName) in the global parameters section and apply the extension
"x-ms-parameter-location": "method". This will then not be a client property.It would be nice to have a linter rule that validates this aspect and warns the user.
CognitiveSerivices api has location as a global parameter and SDKs have shipped with this. It seems odd to pass location while instantiating the client.
The text was updated successfully, but these errors were encountered: