search

spring-cloud / spring-cloud-config

External configuration (server and client) for Spring Cloud
Apache License 2.0
1.96k stars 1.29k forks source link

Add profile to config server response data #1874

Open spencergibb opened 3 years ago

spencergibb commented 3 years ago

Currently, the response from config server contains the profiles used to make the call.

{
  "name": "foo",
  "profiles": [
    "development"
  ]
  ...

As part of ongoing ConfigData changes, it's useful to know the specific profile associated with the property source if applicable. See #1795. This matches profile against the name, but if available in the response, no string matching would be needed.

See https://github.com/spring-projects/spring-boot/issues/25940#issuecomment-820647528

spencergibb commented 3 years ago

Change would be used here https://github.com/spring-cloud/spring-cloud-config/commit/be708efc18b2d503f9f27b3d96cbc668f938aaaa#diff-4f4fd22337a853a8ea94606ab0b8ef10d66426072b00e45e3d27ed18efc79705R150

ryanjbaxter commented 3 days ago

As part of this work we should not return profile specific property sources when no profile is requested.

Currently with any EnvironmentRepository that relies on using NativeEnvironmentRepository (Git and SVN) we use Spring Boot's ConfigDataEnvironmentPostProcessor to load configuration data from the file system.

https://github.com/spring-cloud/spring-cloud-config/blob/0e885745a23d2544d17f82d672a3308b5da2d023/spring-cloud-config-server/src/main/java/org/springframework/cloud/config/server/environment/NativeEnvironmentRepository.java#L143-L154

However the ConfigDataEnvironmentPostProcessor will activate any profiles it finds in those property sources if for example spring.profiles.active or spring.profiles.include is used. This means even if the config client requests config data before any profiles are active that the config server could return profile specific property sources. Ideally if the config client does not request property sources for any profiles the config server would not return those property sources and instead gather all the non-profile specific property sources determine what profiles should be active and then make a second request for the profile specific property sources.

We would need support from Spring Boot in order to implement this, see https://github.com/spring-projects/spring-boot/issues/42932