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

[Rest Level Client] Ai document translation #14749

Merged
37 commits merged into from
Apr 15, 2021
Merged

[Rest Level Client] Ai document translation #14749

37 commits merged into from
Apr 15, 2021

Conversation

joheredi
Copy link
Member

@joheredi joheredi commented Apr 6, 2021

This PR introduces 2 new packages

  • @azure-rest/core-client - which contains shared types and functions that will be reused across generated Rest Level Clients
  • @azure-rest/ai-document-translator - which is an auto generated rest level client that consumes @azure-rest/core-client. for the most part this package is composed of types.

A couple of changes included in this PR

  • Updated dev-tool so that samples work with the new @azure-rest namespace
  • Allow alternate versions for prettier and api-extractor to support newer TS features used in the Rest Level Clients such as Template Literal Types
    • Talked to @deyaaeldeen and there doesn't seem to be any constraint for upgrading Prettier for the whole repo. To keep this PR scoped down to the Rest Level Client work I'll address the upgrade in a separate PR

TODO:

  • @azure-rest/core-client
    • Functionality
    • Readme
    • Tests
  • @azure-rest/ai-document-translator
    • Functionality
    • Samples
    • Readme
    • Tests

Copy link
Member

@xirzec xirzec left a comment

Choose a reason for hiding this comment

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

This is very exciting! I'm really liking how both the codegen and the common code are much simpler.

common/config/rush/common-versions.json Show resolved Hide resolved
sdk/core-rest/core-client/README.md Outdated Show resolved Hide resolved
sdk/core-rest/core-client/src/clientHelpers.ts Outdated Show resolved Hide resolved
sdk/core-rest/core-client/src/clientHelpers.ts Outdated Show resolved Hide resolved
sdk/core-rest/core-client/src/clientHelpers.ts Outdated Show resolved Hide resolved
sdk/documenttranslator/ai-document-translator/package.json Outdated Show resolved Hide resolved
Copy link
Member

@deyaaeldeen deyaaeldeen left a comment

Choose a reason for hiding this comment

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

Looks great! I left a few comments.

sdk/core-rest/core-client/README.md Outdated Show resolved Hide resolved
sdk/core-rest/core-client/review/core-client.api.md Outdated Show resolved Hide resolved
sdk/core-rest/core-client/src/getClient.ts Show resolved Hide resolved
sdk/core-rest/core-client/src/getClient.ts Show resolved Hide resolved
sdk/core-rest/core-client/src/pathClientTypes.ts Outdated Show resolved Hide resolved
sdk/core-rest/core-client/src/sendRequest.ts Outdated Show resolved Hide resolved
return (
url
.toString()
// Remove double forward slashes
Copy link
Member

Choose a reason for hiding this comment

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

could this function be used by core-client's getRequestUrl? I guess we will have to downlevel from OperationSpec to the inputs this function expects.

Copy link
Member

@witemple-msft witemple-msft left a comment

Choose a reason for hiding this comment

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

I left a handful of comments but my "request changes" review is only for the ones in the samples. The others are basically nitpicks.

common/tools/dev-tool/src/util/resolveProject.ts Outdated Show resolved Hide resolved
sdk/core-rest/core-client/src/getClient.ts Outdated Show resolved Hide resolved
sdk/core-rest/core-client/src/pathClientTypes.ts Outdated Show resolved Hide resolved
*/
export type ClientOptions = PipelineOptions & {
credentials?: {
scopes?: string | string[];
Copy link
Member

Choose a reason for hiding this comment

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

Out of curiosity what happens if someone passes something like scopes: ["scope1", "scope2 scope3"]? Do we zip them all together and send the request with "scope1 scope2 scope3"?

Copy link
Member Author

Choose a reason for hiding this comment

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

@azure/core-rest-pipeline's bearerTokenAuthenticationPolicy takes either a string or an array we just pass it as is. I believe at the end if it is a string "scope1" it would be sent out as single item array ["scope1"]

Copy link
Member

Choose a reason for hiding this comment

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

I wonder if we could just always send an array to make this contract simpler

sdk/core-rest/core-client/src/clientHelpers.ts Outdated Show resolved Hide resolved
}

// @public
export interface GetOperations400Response extends HttpResponse {
Copy link
Member

Choose a reason for hiding this comment

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

Seems like the strong type of status isn't doing much here. We end up with a lot of interfaces that contain the exact same information that just have names for which status code they are returning. Seems like an enum use case if what we want is to strictly specify the set of possible status values for errors.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, this is a great point. I'll try to collapse these identical interface into a single one. I'll have to get this working in the generator first. I may not be able to fit it in this PR but I'll definitely address this when sending the Generator PR

@check-enforcer
Copy link

check-enforcer bot commented Apr 8, 2021

This pull request is protected by Check Enforcer.

What is Check Enforcer?

Check Enforcer helps ensure all pull requests are covered by at least one check-run (typically an Azure Pipeline). When all check-runs associated with this pull request pass then Check Enforcer itself will pass.

Why am I getting this message?

You are getting this message because Check Enforcer did not detect any check-runs being associated with this pull request within five minutes. This may indicate that your pull request is not covered by any pipelines and so Check Enforcer is correctly blocking the pull request being merged.

What should I do now?

If the check-enforcer check-run is not passing and all other check-runs associated with this PR are passing (excluding license-cla) then you could try telling Check Enforcer to evaluate your pull request again. You can do this by adding a comment to this pull request as follows:
/check-enforcer evaluate
Typically evaulation only takes a few seconds. If you know that your pull request is not covered by a pipeline and this is expected you can override Check Enforcer using the following command:
/check-enforcer override
Note that using the override command triggers alerts so that follow-up investigations can occur (PRs still need to be approved as normal).

What if I am onboarding a new service?

Often, new services do not have validation pipelines associated with them, in order to bootstrap pipelines for a new service, you can issue the following command as a pull request comment:
/azp run prepare-pipelines
This will run a pipeline that analyzes the source tree and creates the pipelines necessary to build and validate your pull request. Once the pipeline has been created you can trigger the pipeline using the following comment:
/azp run js - [service] - ci

@joheredi joheredi requested a review from witemple-msft April 13, 2021 02:22
Copy link
Member

@witemple-msft witemple-msft left a comment

Choose a reason for hiding this comment

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

Thanks for addressing the issues with the samples and all my little nitpicks. LGTM.

Copy link
Member

@xirzec xirzec left a comment

Choose a reason for hiding this comment

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

Really good job on this, I'm very happy with how the client has turned out!

*/
export type ClientOptions = PipelineOptions & {
credentials?: {
scopes?: string | string[];
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if we could just always send an array to make this contract simpler


// @public
export interface Client {
path: unknown;
Copy link
Member

Choose a reason for hiding this comment

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

We know path will be a function at least, but probably no reason for this type to be pedantic.

Copy link
Member Author

Choose a reason for hiding this comment

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

made it Function

/**
* Represents the shape of an HttpResponse
*/
export type HttpResponse = {
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we should have different types here.

@joheredi
Copy link
Member Author

/azp run automation - pipeline-generation

@azure-pipelines
Copy link

No pipelines are associated with this pull request.

@ghost
Copy link

ghost commented Apr 15, 2021

Hello @joheredi!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit 6314022 into Azure:master Apr 15, 2021
jay-most pushed a commit to jay-most/azure-sdk-for-js that referenced this pull request Apr 26, 2021
This PR introduces 2 new packages

- `@azure-rest/core-client` - which contains shared types and functions that will be reused across generated Rest Level Clients
- `@azure-rest/ai-document-translator` - which is an auto generated rest level client that consumes `@azure-rest/core-client`. for the most part this package is composed of types.

A couple of changes included in this PR
- Updated dev-tool so that samples work with the new `@azure-rest` namespace
- Allow alternate versions for `prettier` and `api-extractor` to support newer TS features used in the Rest Level Clients such as Template Literal Types 
   - Talked to @deyaaeldeen and there doesn't seem to be any constraint for upgrading Prettier for the whole repo. To keep this PR scoped down to the Rest Level Client work I'll address the upgrade in a separate PR

TODO:

- [x] @azure-rest/core-client
   - [x] Functionality
   - [x] Readme
   - [x] Tests 
- [x] @azure-rest/ai-document-translator
   - [x] Functionality
   - [x] Samples
   - [x] Readme
   - [x] Tests
openapi-sdkautomation bot pushed a commit to AzureSDKAutomation/azure-sdk-for-js that referenced this pull request Aug 2, 2021
add apitestErrorCode doc (Azure#14749)

* add apitestErrorCode doc

* add armRPC doc

* add roundTripInconsistentProperty doc

* small fix

* update

* update signalR armTemplate

* update yaml

* new file

* add testScenario with armTemplate

* update doc

* update readme.md

* update doc

* update NOTE section

* add signalRCreateOrUpdate example file

* udpate doc

* add generate test scenario section

* update doc

* add serviceFacbric test scenario file

* update managedClusters.yaml

* update generateABasicTestScenario.md

* update features doc

* add run api test gif
openapi-sdkautomation bot pushed a commit to AzureSDKAutomation/azure-sdk-for-js that referenced this pull request Aug 2, 2021
add apitestErrorCode doc (Azure#14749)

* add apitestErrorCode doc

* add armRPC doc

* add roundTripInconsistentProperty doc

* small fix

* update

* update signalR armTemplate

* update yaml

* new file

* add testScenario with armTemplate

* update doc

* update readme.md

* update doc

* update NOTE section

* add signalRCreateOrUpdate example file

* udpate doc

* add generate test scenario section

* update doc

* add serviceFacbric test scenario file

* update managedClusters.yaml

* update generateABasicTestScenario.md

* update features doc

* add run api test gif
This pull request was closed.
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