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

Draft: Selective api poc #3129

Closed
wants to merge 21 commits into from
Closed

Draft: Selective api poc #3129

wants to merge 21 commits into from

Conversation

zhumin8
Copy link
Contributor

@zhumin8 zhumin8 commented Aug 21, 2024

DO NOT MERGE.
This is a draft pr as prototype to changes for selective api generation feature.
The changes in this pr include api-common-java changes copied over manually for testing purposes.

@product-auto-label product-auto-label bot added the size: xl Pull request size is extra large. label Aug 21, 2024
@zhumin8 zhumin8 added do not merge Indicates a pull request not ready for merge, due to either quality or timing. and removed size: xl Pull request size is extra large. labels Aug 21, 2024
…atches proto package in parser. other cleanups and minor fixes.
@product-auto-label product-auto-label bot added the size: xl Pull request size is extra large. label Aug 23, 2024
@zhumin8 zhumin8 removed the do not merge Indicates a pull request not ready for merge, due to either quality or timing. label Aug 26, 2024
return fileDescriptor.getServices().stream()
.filter(
serviceDescriptor -> {
List<MethodDescriptor> methodsList = serviceDescriptor.getMethods();
if (methodsList.isEmpty()) {
List<MethodDescriptor> methodListSelected =
Copy link
Collaborator

Choose a reason for hiding this comment

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

This scenario is in case that all methods from a service are excluded?

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. And this is likely now e.g. in vertexai's requirement it only exposes methods from 2 services.

@@ -425,6 +434,47 @@ public static List<Service> parseService(
Transport.GRPC);
}

private static Optional<List<String>> getInclusionMethodListFromServiceYaml(
Optional<com.google.api.Service> serviceYamlProtoOpt, String protoPackage) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

It is usually preferred to not passing around Optional if we can check it before calling the method.

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 want to follow-up on this from our discussion earlier and get @blakeli0 your opinion on this. (FYI, I've combined this method into shouldIncludeMethodInGeneration() )
For now, I am slightly inclined to keep this Optional<com.google.api.Service> serviceYamlProtoOpt as input for 2 reasons:

  • The pattern of passing in this Optional is repeated in this Parser class, a larger scale refactor is needed to remove these.
  • Because this service yaml is an optional config file that only some libraries have, it sort of make sense to have this Optional representation. And I find the current way can better encapsulate this piece of logic: shouldIncludeMethodInGeneration() has all the information to decide if this method should or not be included. I could check serviceYamlProtoOpt before calling the method, but the 2 occurrences would repeat the logic in a reverse way, and it might be less readable for debugging in the future.

Does this makes sense to you? WDYT?

@@ -705,6 +710,99 @@ void parseServiceWithNoMethodsTest() {
assertEquals("EchoWithMethods", services.get(0).overriddenName());
}

@Test
void selectiveGenerationTest_shouldExcludeUnusedResourceNames() {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This test verifies that unused resource names (associated with methods not in inclusion list) will not be populated to GapicContext.

@@ -425,6 +434,39 @@ public static List<Service> parseService(
Transport.GRPC);
}

private static boolean shouldIncludeMethodInGeneration(
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we make this a default scope method so we can test it directly? This would enabled us testing more scenarios like the non matching packages, it would also simplify the golden tests.

Copy link
Collaborator

Choose a reason for hiding this comment

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

We probably don't need this yaml and selective_api_generation_no_publishing_v1beta1.yaml as the scenarios should be tested in ParserTest directly.

zhumin8 added a commit that referenced this pull request Nov 5, 2024
@zhumin8
Copy link
Contributor Author

zhumin8 commented Nov 7, 2024

implemented in #3323. closing

@zhumin8 zhumin8 closed this Nov 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size: xl Pull request size is extra large.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants