-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
Conversation
Automation for azure-sdk-for-pythonA 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: |
Automation for azure-sdk-for-nodeA 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: |
Automation for azure-sdk-for-rubyThe initial PR has been merged into your service PR: |
Can one of the admins verify this patch? |
Automation for azure-sdk-for-goNothing to generate for azure-sdk-for-go |
Automation for azure-sdk-for-javaNothing to generate for azure-sdk-for-java |
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! |
Thanks for the updates @mnltejaswini 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:
|
} | ||
} | ||
}, | ||
"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerRegistry/registries/{registryName}/getBuildSourceUploadUrl": { |
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.", |
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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....
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it
@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 |
@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. |
@johanste Thank you. Will separate the properties. |
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.
@ravbhatnagar I separated the create and update parameters to avoid conflict between required and patchable properties. Can you please review. |
@ravbhatnagar Can you please review |
This was reviewed in person. Signing off! |
Thanks @ravbhatnagar! |
…rguments property to values for Task type requests and steps
@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. |
@annatisch where can I find the validation errors in examples? Never mind, I found them. will update the examples. |
Thanks @mnltejaswini - you can find them here: I will also review the PR today. |
@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. |
… to fix the model validation failures.
There was a problem hiding this 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", |
There was a problem hiding this comment.
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"?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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.
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
api-version
in the path should match theapi-version
in the spec).Quality of Swagger