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

Azure container registry build feature GA API specification and examples. #3617

Merged
merged 13 commits into from
Aug 23, 2018
Merged

Azure container registry build feature GA API specification and examples. #3617

merged 13 commits into from
Aug 23, 2018

Conversation

mnltejaswini
Copy link
Contributor

@mnltejaswini mnltejaswini commented Aug 9, 2018

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

@AutorestCI
Copy link

AutorestCI commented Aug 9, 2018

Automation for azure-sdk-for-python

A PR has been created for you based on this PR content.

Once this PR will be merged, content will be added to your service PR:
Azure/azure-sdk-for-python#3140

@AutorestCI
Copy link

AutorestCI commented Aug 9, 2018

Automation for azure-sdk-for-node

A PR has been created for you based on this PR content.

Once this PR will be merged, content will be added to your service PR:
Azure/azure-sdk-for-node#3337

@AutorestCI
Copy link

AutorestCI commented Aug 9, 2018

Automation for azure-sdk-for-ruby

The initial PR has been merged into your service PR:
Azure/azure-sdk-for-ruby#1574

@azuresdkci
Copy link
Contributor

Can one of the admins verify this patch?

@AutorestCI
Copy link

AutorestCI commented Aug 9, 2018

Automation for azure-sdk-for-go

Nothing to generate for azure-sdk-for-go

@AutorestCI
Copy link

AutorestCI commented Aug 9, 2018

Automation for azure-sdk-for-java

Nothing to generate for azure-sdk-for-java

@annatisch annatisch added the WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required label Aug 9, 2018
@annatisch
Copy link
Member

Adding @ravbhatnagar to review new ARM API version swagger.

@mnltejaswini - there are some model validation errors in the examples - could you take a look?https://travis-ci.org/Azure/azure-rest-api-specs/jobs/414189551

Thanks!

@annatisch
Copy link
Member

Thanks for the updates @mnltejaswini
Could you please update the readme tag so that the generated SDKs pick up the latest API version?
https://github.com/Azure/azure-rest-api-specs/pull/3617/files#diff-4837e14bb0f77202f522d1f223f87c3aR29

Unless you have a particular reason not to publish SDKs for this API?

Finally, there's still a couple of errors in the Tasks_Get example:

 error: 
operationId: Tasks_Get
scenario: Tasks_Get
source: response
responseCode: '200'
severity: 0
errorCode: OBJECT_MISSING_REQUIRED_PROPERTY
errorDetails:
  code: OBJECT_MISSING_REQUIRED_PROPERTY
  params:
    - name
  message: 'Missing required property: name'
  path: properties/trigger/sourceTriggers/0
  title: SourceTrigger
  description: The properties of a source based trigger.

 error: 
operationId: Tasks_Get
scenario: Tasks_Get
source: response
responseCode: '200'
severity: 0
errorCode: OBJECT_MISSING_REQUIRED_PROPERTY
errorDetails:
  code: OBJECT_MISSING_REQUIRED_PROPERTY
  params:
    - name
  message: 'Missing required property: name'
  path: properties/trigger/baseImageTrigger
  title: BaseImageTrigger
  description: The trigger based on base image dependency.

}
}
},
"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerRegistry/registries/{registryName}/getBuildSourceUploadUrl": {
Copy link
Member

Choose a reason for hiding this comment

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

Is this API ever expected to be consumed from an ARM template? If so, @ravbhatnagar, is it still true that the name should be list*** (regardless of how many items are actually returned)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, you are correct. It cannot be called from ARM template if it is not prefixed with list. There is no use case for this API to be called from template

Copy link
Member

Choose a reason for hiding this comment

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

In general, I've often found that there are scenarios for consuming pretty much any computed value from within a template. So, my default recommendation is to take an "assume it will be consumed from within a template unless proven otherwise" approach. But this is a general statement. If you truly don't have any scenarios where one would, say, provision a virtual machine that needs the access the value (or that user assigned identities would enable the access from the resource itself), then this is all good.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I renamed it to prefix with list so that it can be invoked from template.

{
"name": "$filter",
"in": "query",
"description": "The runs filter to apply on the operation.",
Copy link
Member

@johanste johanste Aug 14, 2018

Choose a reason for hiding this comment

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

What capabilities does the filter have? Full odata (operators and all properties)? If not, specifying what the user can put in the $filter in the description is very helpful for callers...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Makes sense. there are some restrictions on the odata query , I will add them to the description.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I updated the description to include restrictions on filter.

"format": "int32"
},
{
"name": "$skipToken",
Copy link
Member

Choose a reason for hiding this comment

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

How would the user get the skip token value? If the only way to get it is from a nextLink in the response, then there is limited value in documenting the parameter, since the only way that the user can get it is by parsing the URL, and then putting it back into the API to build up exactly the same URL as they got in the nextLink to begin with....

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The nextLink is self contained and can be invoked as is. Please correct me if my understanding is wrong?

Copy link
Member

Choose a reason for hiding this comment

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

Is there some other way that I, as a user, can determine what value I could possibly pass in for the $skipToken parameter?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, the only way is from nextLink

Copy link
Member

Choose a reason for hiding this comment

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

@mnltejaswini - I think what @johanste is saying is that you can probably remove this parameter because the generated SDKs already support retrieving the next page directly from nextLink - so unless there's a particular situation where a customer would need to extract the skipToken from nextLink, it's not really necessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Got it

@mnltejaswini
Copy link
Contributor Author

@johanste Is it allowed for the PATCH and PUT request payload is of same type? The lint checker complaints about the conflicts between required and patchable properties. So we either remove Required for Task and do only server validation versus separate the create and update parameters. Which one is preferred? Can you please advise

@johanste
Copy link
Member

@mnltejaswini, having required parameters for a PATCH request body rarely makes sense. You want to provide only the value that you want to modify, which is orthogonal to if they are required on create/PUT.

The most common pattern is to have separate models. Unfortunately, there is no way in swagger/openapi to have selectively required parameters depending on the point of usage.

@mnltejaswini
Copy link
Contributor Author

@johanste Thank you. Will separate the properties.

@ravbhatnagar
Copy link
Contributor

pending a couple of updates from @mnltejaswini. Please let me know once you are ready and I can review.

…ers to avoid conflict between required nd patchable properties.
@mnltejaswini
Copy link
Contributor Author

@ravbhatnagar I separated the create and update parameters to avoid conflict between required and patchable properties. Can you please review.

@mnltejaswini
Copy link
Contributor Author

@ravbhatnagar Can you please review

@ravbhatnagar
Copy link
Contributor

This was reviewed in person. Signing off!

@ravbhatnagar ravbhatnagar added ARMSignedOff <valid label in PR review process>add this label when ARM approve updates after review and removed WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required labels Aug 22, 2018
@annatisch
Copy link
Member

Thanks @ravbhatnagar!
@mnltejaswini - could you please take a look at the validation errors in the examples?

…rguments property to values for Task type requests and steps
@mnltejaswini
Copy link
Contributor Author

@ravbhatnagar As per the review board feedback, there are minor changes, added isArchiveEnabled as part of schedule run request and renamed the arguments to values property for task type step and run requests.

@mnltejaswini
Copy link
Contributor Author

mnltejaswini commented Aug 23, 2018

@annatisch where can I find the validation errors in examples? Never mind, I found them. will update the examples.

@annatisch
Copy link
Member

Thanks @mnltejaswini - you can find them here:
https://travis-ci.org/Azure/azure-rest-api-specs/jobs/419797791

I will also review the PR today.

@mnltejaswini
Copy link
Contributor Author

@annatisch They doesn't seem to be valid. The payload for GET and PUT is the same, while we can PUT some sensitive information as part of resource creation, we cannot return them as part of GET. This has be the pattern we were using for all our resources.

Copy link
Member

@annatisch annatisch left a comment

Choose a reason for hiding this comment

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

Just a few small things :)

"Registries"
],
"description": "Get the upload location for the user to be able to upload the source.",
"operationId": "Registries_ListBuildSourceUploadUrl",
Copy link
Member

Choose a reason for hiding this comment

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

I see this operation has been changed from "GetBuildSourceUploadUrl" to "ListBuildSourceUploadUrl".
Given that it doesn't actually list anything - could we please change it back to "GetBuildSourceUploadUrl"?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

same here, in the swagger review, it is recommended to prefix it with list so that they can be used in ARM template.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks @mnltejaswini - the operation ID is only for the generated clients and does not impact the URL or ARM templates.

"description": "The run update properties.",
"required": true,
"schema": {
"$ref": "#/definitions/RunUpdateParameters"
Copy link
Member

Choose a reason for hiding this comment

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

Does this mean that a customer can only update the Run "isArchiveEnabled"? And not any of the subclass specific fields (e.g. DockerBuildRequest.image_names etc etc)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, the only property that is patchable in the run is isArchiveEnabled

"Tasks"
],
"description": "Returns a task with extended information that includes all secrets.",
"operationId": "Tasks_ListDetails",
Copy link
Member

Choose a reason for hiding this comment

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

This operation should be renamed to "Tasks_GetDetails" - as the response does not list anything.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We renamed it that way so that it can be used in ARM template

Copy link
Member

Choose a reason for hiding this comment

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

Thanks @mnltejaswini - the operation ID is only for the generated clients and does not impact the URL or ARM templates.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see, ok then I will change the operation ID

"format": "int32"
},
{
"name": "$skipToken",
Copy link
Member

Choose a reason for hiding this comment

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

@mnltejaswini - I think what @johanste is saying is that you can probably remove this parameter because the generated SDKs already support retrieving the next page directly from nextLink - so unless there's a particular situation where a customer would need to extract the skipToken from nextLink, it's not really necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ARMSignedOff <valid label in PR review process>add this label when ARM approve updates after review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants