spring-cloud-gcp: CloudSqlEnvironmentPostProcessor not compatible with Spring Cloud Bootstrap PropertySourceLocator mechanism

I discovered that the new CloudSqlEnvironmentPostProcessor within Spring Cloud GCP 2.x causes issues when you combine it with properties that are being loaded via a PropertySource that is created via the Spring Cloud Bootstrap PropertySourceLocator. The reason is that the properties loaded via a PropertySource that is created by a PropertySourceLocator are loaded after the CloudSqlEnvironmentPostProcessor is executed.

The case in which we discovered this is as follows:

• In the application.yml, on the classpath, the property spring.cloud.gcp.sql.enabled is set to false
• When the application is deployed to a GKE environment, Spring Cloud Kubernetes is used to load a Kubernetes ConfigMap, via the Kubernetes API so the ConfigMap is not mounted in the container, and this ConfigMap contains the same spring.cloud.gcp.sql.enabled property but it set to true
• The intention is to have CloudSQL disabled when developing locally, but it is used when running the application within GKE.
• When deploying in GKE with the ConfigMap, the spring.cloud.gcp.sql.enabled=true is never picked up by the CloudSqlEnvironmentPostProcessor and thus it doesn’t do its thing to setup the required correct Datasource for CloudSQL. The application fails to startup.
• The issue is that Spring Cloud Kubernetes uses the Spring Cloud Bootstrap PropertySourceLocator mechanism to create a PropertySource for the ConfigMap but this happens when the ApplicationContextInitializers are executed, which is after the EnvironmentPostProcessor have been executed in the normal application context startup phase (so the PropertySourceLocator is only created in the bootstrap contact startup phase and executed in the application context startup phase). Because of that the CloudSqlEnvironmentPostProcessor never sees the properties from the ConfigMap PropertySource.

To figure out what was going on took some time. In the end, there are plenty workaround like simply mounting the ConfigMap and loading via one of the ways that Spring Boot has to load configuration, but it would be best if the CloudSQL support mechanism in Spring Cloud GCP would simply be compatible with Spring Cloud Bootstrap and it all works as expected.

I am not sure what a good solution is. Maybe go back to the mechanism from Spring Cloud GCP 1.x?

Sample I have not provided a code sample, as this is requires fairly complicated setup to demonstrate the issue. I hope that the explanation above suffices to make the issue clear.