I reported this in spring-boot but the issue is with the spring-cloud-config client.
https://github.com/spring-projects/spring-boot/issues/26116
Using a config server, in the application.yml I have defined a group:
# application.yml
spring:
profiles:
group:
dev:
- local
- other
In my application configuration, I'm making use of the other profile:
# my-service.yml
spring:
datasource:
url: jdbc:...
---
spring:
config:
activate:
on-profile: other
some:
other:
setting: true
When running the application with the dev profile, I expected to see the some.other.setting=true property. However, the file seems to be skipped and the property is therefore missing. Looking at the output of the HTTP request to config server, I see that both documents in my-service.yml are returned - the default and the one activated by the other profile.
I'm currently using Spring Boot 2.4.4 and Spring Cloud Config Client 3.0.3.
Comment From: nickcaballero
From @philwebb - https://github.com/spring-projects/spring-boot/issues/26116#issuecomment-820590935:
I believe this might related to the Spring Clould Config Client
ConfigDataLocationResolver. The current code uses resolveProfileSpecific to provide config data. This method is only called after profiles have been resolved so I don't think it can contribute profile groups.
Other implementations of the ConfigDataLocationResolver in the Spring Cloud project are doing the same, which would mean that none of them can contribute to the profile groups.
Comment From: spencergibb
For config server it will require a new two call process to config server. So this won't come soon. For the others it's easier.
Comment From: VonUniGE
Not being able to use spring.profile.group property with spring-cloud-config prevent us to remove spring.config.use-legacy-processing=true from our configurations and thus to use Spring Boot 3.
@spencergibb Is there any projection on when a fix will be available or is there any workaround (other than activating each profile individually)?