test: restore showcase autogen IT

[diegomarquezp]

Fixes #2214 🔨

Context

So far, this test used bazel + a few string manipulations in sdk-platform-java's showcase BUILD file and WORKSPACE file. This wasn't working since we migrated showcase generation to our hermetic build scripts. This PR transforms the test into using protoc directly

Approach

It's very similar to generate_library.sh in the sense that we infer the protoc version and then use the spring-cloud-generator jar as a plugin to protoc to compile the showcase protos, which are downloaded in the script.

Other changes

• Update showcase generated autoconfigs. Includes changes from updating gapic-showcase to a new version. See test: add showcase test for api-version googleapis/sdk-platform-java#2737 .
• Changes in the autoconfig composer, specifically about explicitly setting the endpoint to [Service]Settings.getDefaultEndpoint(). The beans would fail to load otherwise. cc: @lqiu96
• Include the generation of a jar-with-dependencies for spring-cloud-generator. Apparently bazel was able to figure out how to inject dependencies in the generation runtime. Now we need to create a jar with all dependencies as we run protoc directly with the jar.
• Added a wrapper executable script for the autoconfig generator. This is due to how protoc takes plugins.

[diegomarquezp]

This is in order to run the spring generator jar using dependencies such as protobuf classes. This was something bazel took care about with the previous setup.

[diegomarquezp]

Not sure if this is what we want when creating client settings. We can follow up with proper changes in gax.
cc: @lqiu96

[lqiu96]

Do you have the error message if you don't add this line to set the endpoint? Ideally, we shouldn't have to set the endpoint ourselves but for this PR, I think it's fine we can't resolve the issue here.

Or if this isn't becuase of an error, is this because we're using an old version of the generator. Or perhaps this is just something spring generator does?

[diegomarquezp]

Do you have the error message if you don't add this line to set the endpoint?

The error message:

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'echoClient' defined in com.google.showcase.v1beta1.spring.EchoSpringAutoConfiguration: Failed to instantiate [com.google.showcase.v1beta1.EchoClient]: Factory method 'echoClient' threw exception with message: Invalid host or port: .googleapis.com 443
	at org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:648)
	at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:636)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1335)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1165)

It fails to resolve the endpoint if we don't explicitly set it: Invalid host or port: .googleapis.com 443

Or if this isn't because of an error, is this because we're using an old version of the generator. Or perhaps this is just something spring generator does?

I don't think this is very different from a normal use case of instantiating a client with a few settings.

Here we create the settings:

spring-cloud-gcp/spring-cloud-generator/showcase/showcase-spring-starter/src/main/java/com/google/showcase/v1beta1/spring/EchoSpringAutoConfiguration.java

Lines 115 to 121 in 0f94e07

	@Bean
	@ConditionalOnMissingBean
	public EchoSettings echoSettings(
	@Qualifier("defaultEchoTransportChannelProvider")
	TransportChannelProvider defaultTransportChannelProvider)
	throws IOException {
	EchoSettings.Builder clientSettingsBuilder;

Here we create the client with these settings:

spring-cloud-gcp/spring-cloud-generator/showcase/showcase-spring-starter/src/main/java/com/google/showcase/v1beta1/spring/EchoSpringAutoConfiguration.java

Lines 339 to 343 in 0f94e07

	@Bean
	@ConditionalOnMissingBean
	public EchoClient echoClient(EchoSettings echoSettings) throws IOException {
	return EchoClient.create(echoSettings);
	}

[lqiu96]

It fails to resolve the endpoint if we don't explicitly set it: Invalid host or port: .googleapis.com 443

Ah, I think this is an edge case due to the the showcase protos. The showcase protos have a default_host value that won't match a "normal" google endpoint. For example, the echo proto's service_host value: https://github.com/googleapis/gapic-showcase/blob/4e7c30a5d5df8aac30e8b8f1e6f71809fa9d20f6/schema/google/showcase/v1beta1/echo.proto#L45
where as a normal endpoint would be something like cloudassets.googleapis.com.

The error above is complaining that we can't populate the serviceName part of the endpoint and that's because the showcase protos don't have one. That's why you'd have to explicitly call setEndpoint() yourself.

This looks like it's changing the code inside the generator, which I believe would impact all of spring code gen. The endpoint normally should be constructed internally for non-showcase services and I believe having the generator explicitly call setEndpoint() may be imcompatible with enabling certain features.

In the showcase ITs, we have this same problem. But we solve it by explicitly calling setEndpoint() in the handwritten layers: https://github.com/googleapis/sdk-platform-java/blob/5799827a864be627bac03969cc178efc9d6170aa/showcase/gapic-showcase/src/test/java/com/google/showcase/v1beta1/it/util/TestClientInitializer.java#L67

I'm not too familiar with the showcase autogen ITs. Are there any handwritten parts that we can do something similar or are these the only tests that are generated + run?

[blakeli0]

Are there any handwritten parts that we can do something similar or are these the only tests that are generated + run?

This is the handwritten test.Compare to GAPIC showcase tests, this test though does not create a client, instead, it fetches the client from existing Spring beans. So it's hard to override the endpoint in the tests since the whole point of SpringCodeGen is to create a client for customers.

I think this change might be unavoidable for now, and should not impact any existing features, because SpringCodeGen does not expose a property for customers to set endpoint or universe domain either. We can revisit this decision once we get to implement universe domain in spring-cloud-gcp. WDYT @lqiu96 ?

[lqiu96]

I see. I'm not too familiar with spring so I don't know of a way to do this, but we are going to have to remove the explicit setting for the default endpoint at some point (i.e. whenever we enable universe domain). This will require a workaround for the showcase clients in the future or more configurations generated by the generator.

I think for now we can proceed with explicitly setting the default endpoint.

[blakeli0]

How many utility methods in utilities.sh are we relying on? If it's not too much, I would prefer just duplicate the logic, because this creates dependencies of our hermetic build scripts, and we may accidentally break SpringCodeGen scripts.

[blakeli0]

I don't think we need these additional protos, same thing for rest_numeric_enums, transport, gapic_yaml, include_samples etc. Can you try to remove them and see if the checks are still passing?

[burkedavison]

Everything below uses ${output_folder}, but this uses literal value output.

[burkedavison]

LGTM

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud