as a developer, I’m wondering about the management of configuration properties in Quarkus. And in particular how to share (expose/contract) custom application properties that should be modified/valued in environments by ops.
Just as with OpenAPI-type contractualization, it would seem useful to have both the keys to be valued and the associated documentation, so as to know what the property is used for, in order to be able to value it correctly at runtime.

In fact, in the “application.properties” file, apart from properties specific to the framework (“quarkus.*”), this is also where properties specific to the application will be added. And some or all of these properties should be modified at runtime, depending on the deployment environment.
However, as the “application.properties” file is embedded in the generated artifact (JAR), there is no way for the person in charge of the binary to know which properties should be set at runtime (except unziping the file…)…
Of course, this can be achieved through documentation, but as is often the case, there is a risk of a mismatch between documentation and code, i.e. between documented properties and the application properties actually present in the embedded “application.properties”…
A centralized system such as Consul could perhaps simplify this problem, but I’d rather not use it at the moment.

There’s another post on this subject (How to get all Quarkus application configuration properties and their values?) and it shows the use of the annotation:

@ConfigRoot(phase = ConfigPhase.RUN_TIME)

to generate a doc (ascidoc?) with the associated conf. Is this a good practice?

There’s also this post: Centralize common config for quarkus which talks about copying (manual operation!?) the “config/application.properties” file next to the artifact to be deployed to the deployment destination.
This is more or less the direction I’m going in, by relying on Maven and generating an additional artifact (based on the Assembly plugin) to generate an archive containing the “application.properties” file with values in Ansible format ({{…}}). Delivering this artifact allows operators to know which properties are to be valued.
But it’s a bit of a departure from the Quarkus ecosystem, which seems to be very rich. And I’m a little surprised not to find a more standard (“official”) solution. Or maybe I’m missing something…

Thanks for your help