Improve testing gRPC services with random ports

[nahguam]

Currently, testing gRPC is not as seamless as HTTP when it comes to using random ports. If one injects a @GrpcClient when quarkus.grpc.server.test-port=0, it will attempt to connect to port 0, or if one is using the Vert.x server, it will attempt to connect to the http test port, 8081.

This change aims to improve this by making it possible to inject @GrpcClients into tests that have discovered the actual port that the service is running on. It shares the approach that is used for HTTP.

[jbonofre]

@nahguam Thanks ! I'm doing a pass/review.

[alesj]

Where in the docs does it state if you pass 0 port to (Vert.x) gRPC server, that it randomly selects one?
(not that I'm doubting this is true ... just curious)

Plus, it would also be good/nice to fix to actual port where ever we print it out.
e.g.

            msg += String.format("gRPC server on %s:%d [%s]",
                    configuration.host, port, "TLS enabled: " + !configuration.plainText);

Otherwise it looks good + nice test coverage!

[nahguam]

Where in the docs does it state if you pass 0 port to (Vert.x) gRPC server, that it randomly selects one? (not that I'm doubting this is true ... just curious)

To my limited knowledge, the only reference is https://github.com/quarkusio/quarkus/blob/main/docs/src/main/asciidoc/http-reference.adoc#7-listening-on-a-random-port

Should I add similar detail to the grpc doc?

Plus, it would also be good/nice to fix to actual port where ever we print it out. e.g.

            msg += String.format("gRPC server on %s:%d [%s]",
                    configuration.host, port, "TLS enabled: " + !configuration.plainText);

Indeed, I did have a look at this but it looked non-trivial. I'll take another look.

[nahguam]

Plus, it would also be good/nice to fix to actual port where ever we print it out. e.g.

            msg += String.format("gRPC server on %s:%d [%s]",
                    configuration.host, port, "TLS enabled: " + !configuration.plainText);

Indeed, I did have a look at this but it looked non-trivial. I'll take another look.

I've updated this output.

[alesj]

Should I add similar detail to the grpc doc?

Are we sure this works for the gRPC as well? :-)
Since I guess that is then a (pure) gRPC thing (not http / Vert.x)

[alesj]

Well, this was easy. :-)
Are we sure we captured all such log outputs -- with this "new" port?

[nahguam]

There's an output in buildServer but that's before the server is started - so before the port is chosen.

[cescoffier]

LGTM!

You can retrieve the actual port from the httpServer (once bound to the socket): `server.getactualPort()).

[jbonofre]

LGTM, thanks !

[quarkus-bot]

Failing Jobs - Building ea149e1

Status	Name	Step	Failures	Logs	Raw logs
⌛	Native Tests - Misc3	Build	⚠️ Check →	Logs	Raw logs
✖	Native Tests - Windows - RESTEasy Jackson	Setup GraalVM	⚠️ Check →	Logs	Raw logs

[nahguam]

Should I add similar detail to the grpc doc?

Are we sure this works for the gRPC as well? :-) Since I guess that is then a (pure) gRPC thing (not http / Vert.x)

Do you mean when use-separate-server=true? If so, yes, the tests cover that.

[nahguam]

Do I need to keep rebasing on main? (it moves so quickly! :D)

Looks like the failure is unrelated. What needs to happen now?

[jbonofre]

@nahguam Clément and I approved this PR, so I think we are good to go. No need to keep rebasing, we can alway rebase when merging. @cescoffier thoughts ?

[cescoffier]

I was just waiting for 3.2 to be branched.

[jbonofre]

@cescoffier great, thank you 😄

[nahguam]

Great Thanks 👍