Skip to content
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

Add support for policy at ManagementGroup level #1754

Merged
merged 3 commits into from
Oct 2, 2017

Conversation

vivsriaus
Copy link
Contributor

@vivsriaus vivsriaus commented Sep 27, 2017

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.

PR information

  • The title of the PR is clear and informative.
  • There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
  • Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
  • If applicable, the PR references the bug/issue that it fixes.
  • Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

@azuresdkciprbot
Copy link

Hi There,

I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:

File: specification/resources/resource-manager/readme.md
Before the PR: Warning(s): 0 Error(s): 0
After the PR: Warning(s): 0 Error(s): 0

💡 Please review potentially introduced Error(s)/Warning(s): Analysis Report 💡

AutoRest Linter Guidelines | AutoRest Linter Issues | Send feedback

Thanks for your co-operation.

"in": "path",
"required": true,
"type": "string",
"description": "The ID of the management group."
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: @sarangan12 is still the assigned reviewer. He will be finally reviewing the spec.
@vivsriaus - I noted an anomaly that I wanted to point out. Whenever you define a parameter in the global "prameters" section, Autorest treats it as a client property. This will end up as a required parameter in the constructor. I am sure this is not motive over here. It is ok to define parameters in the global parameters section so that you can reference it at multiple places in the swagger spec. However, if the parameter should not be a client property then please add the following extension: "x-ms-parameter-location": "method".
There is an issue filed in the linter repo for checking this Azure/azure-openapi-validator#84

Azure/azure-openapi-validator#84

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @amarzavery thanks for the comment. I'm not sure what a client property is. What do you mean when you say"required parameter in the constructor"? You mean of the policy client?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @vivsriaus - That is correct. The constructor of the policy client will have a required parameter named managementGroupId. An example TypeScript client:

class PolicyClient {
 . . .
  constructor(subscriptionId: string, managementGroupId: string, baseUri: string?, options: OptionalParams) {
   . . .
  }
}

This would be the case in C# and other languages as well. I am sure this is not the desired behavior. If so then please add the extension "x-ms-parameter-location": "method" to the parameter in this and the other swagger spec below.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @amarzavery. Yes, we definitely don't want managementGroupId to be a required parameter in the constructor. I'll make the changes.

"in": "path",
"required": true,
"type": "string",
"description": "The ID of the management group."
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as above.

@azuresdkciprbot
Copy link

Hi There,

I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:

File: specification/resources/resource-manager/readme.md
Before the PR: Warning(s): 0 Error(s): 0
After the PR: Warning(s): 0 Error(s): 0

💡 Please review potentially introduced Error(s)/Warning(s): Analysis Report 💡

AutoRest Linter Guidelines | AutoRest Linter Issues | Send feedback

Thanks for your co-operation.

@sarangan12 sarangan12 merged commit 3022628 into Azure:current Oct 2, 2017
@AutorestCI
Copy link

No modification for AutorestCI/azure-sdk-for-node

@AutorestCI
Copy link

@AutorestCI
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants