External test tool (httpyac) and keycloak dev services url(s)

[col-panic]

I do integrate httpyac to write documentation and tests for my rest interface. In order to execute
the test I have an environment definition like

base_url=http://localhost:8080

endpoint_fhir_r4={{base_url}}/fhir/r4
endpoint_api_v1={{base_url}}/api/v1/management

keycloak-url=http://localhost:50363/realms/quarkus/protocol
oauth2_clientId=quarkus-app
oauth2_clientSecret=secret
oauth2_tokenEndpoint={{keycloak-url}}/openid-connect/token
oauth2_authorizationEndpoint{{keycloak-url}}/openid-connect/auth
oauth2_deviceCodeEndpoint={{keycloak-url}}/openid-connect/auth/device
oauth2_username=ict-administrator
oauth2_password=ict-administrator

you see the line keycloak-url which defines the access port to the dev environment managed keycloak.

Now every time I restart quarkus with mvn quarkus:dev a new keycloak container gets started and assigned
a new port. Quarkus knows about the port, but I'm struggling on how to get the info to the http testing tool.
Currently I always need to update the port manually.

• Is there maybe a fixed dev-services endpoint I can gather the values from?
• Could we possibly generate an .env file on starting with mvn quarkus:dev that might provide local variables to third party software?

[sberyozkin]

@col-panic Can starting Keycloak devservice on a fixed port help ?

[col-panic]

@sberyozkin thanks for the response - yes it does! Docker does map the port to the configured value! But what would happen if the referenced port is already used by another application? Would there be a startup failure or would it just assign another random one?

[sberyozkin]

@col-panic Yes, it would fail. We could allocate the random number in this case but then if a random port fallback is acceptable, then it means the fixed port is not really important.

Could we possibly generate an .env file on starting with mvn quarkus:dev that might provide local variables to third party software?

I think this could be a wider level devmode enhancement request, as it can also be relevant for other devservices.

@phillip-kruger, @radcortez, what do you think ?

[radcortez]

The tricky part is what to include. A simple REST application has over 600 configurations; if you have a Quarkus application with all extensions from the core, it has over 6000 configurations.

We can certainly do it, I'm just not sure if users would appreciate such file :)

Generating the file shouldn't be too hard. For now, my recommendation is to just have a @Startup bean that dumps the configuration required by the user. For that, you can inject a SmallRyeConfig and call getPropertyNames to get the list of available configuration names and pick the ones you want to include, by calling getValue on the name.