I’ve recently had a problematic non-native Quarkus service deployment to production, because one of the production profiles on the classpath application.yaml had a configuration misspelling that was only picked up when trying to start the service in production.

For example, in my classpath:application.yaml I had something like:

 a.prop: value
 
 "%prod-aws-1":
   a.prop: override-for-aws-1
 
 "%prod-aws-2":
   a.prrop: override-for-aws-2 #<-- oops misspelt the name

During dev and testing this never was a problem because Quarkus presumably never checked the specific production profile during these times. Only when actually running the service with the prod-aws-2 profile, did the problem manifest.

As an aside and perhaps a follow-up question, I tried fixing the problem by adding the correct configuration in the external config/application.yaml, but the quarkus startup still failed because it could not find a mapping for the misspelt configuration on the classpath application.yaml. Which kind of makes sense but also limits the ability to fix the problem on the spot without digging into the jar file.

My question is, is it possible at development time to verify a specific Quarkus configuration profile without actually running the service? I’m looking for something like:

quarkus config verify-profile prod-aws-2

perhaps using the CLI, which would parse the configuration and let you know if there is a configuration mismap.