spring cloud config searchPaths

Question

I'm looking at implementing the 12factor approach to externalising config via Spring Cloud Config but am not able to get the wildcards working using searchPaths as I expected.

The documentation http://cloud.spring.io/spring-cloud-config/spring-cloud-config.html#_spring_cloud_config_server mentions that wildcards {application}, {label}, {profile} can be used within the searchPaths variable so that "you can segregate the directories in the path, and choose a strategy that makes sense for you (e.g. sub-directory per application, or sub-directory per profile)."

I'm looking to have a single git repo, with either subdirectories per profile (and then per app, or subdirectory per app (then by profile).

e.g.

    spring:
      cloud:
        config:
          server:
            git:
              uri: https://stash.xxx.com.au/scm/xxx/config
              searchPaths: {application}
or
              searchPaths: {profile}
or
              searchPaths: {application}/{profile}

However when I use any of the wildcards {application} or {profile} in my searchPaths it doesn't find the data in the git repo, or for the concatenated option fails to startup at all.

Does anyone have a working example of this I can refer to? Cheers Roy

Answer 1

Use single quote and it works fine.

searchPaths: '{application}'

Hope this helps if someone stumbles across this problem.

Answer 2

In addition to above, and more importantly if you want your common configuration (e.g. application.yml) which is shared across multiple applications per environment, to be read. Then place application.yml in a folder (say - common), then the config goes like this:

searchPaths:
  - '{application}'
  - common

{application} resolves to the value of 'spring.application.name' in the config clients' bootstrap.yaml.

Reference: https://cloud.spring.io/spring-cloud-config/multi/multi__spring_cloud_config_server.html#_placeholders_in_git_search_paths

Answer 3

I thought it might be useful to post our configuration, since it demonstrates the priority order of multiple search paths. The native backend search-order property is documented pretty well, but it wasn't clear to me that git backend search-paths works the same way.

This is with Spring Cloud release train 2020.0.2:

spring:
  cloud:
    config:
      server:
        git:
          uri: /path/to/git/repo
          search-paths:
            - /defaults
            - "env_{profile}"

Properties found at later search-paths override ones found earlier.

Example of use:

• We default SQL logging = true for all services and environments in defaults/application.yml. So it's effective in TEST, QA, and UAT.
• We could override the default for a specific application in defaults/specific_app_name.yml (we don't for SQL logging).
• In production we turn off all SQL logging, in env_prod/application.yml.
• If needed we can turn SQL logging on for a single production service, by adding the property to env_prod/specific_app_name.yml.

(Edit: I originally posted 4 search-paths above, but I realized that the last two are not needed for this example, and in fact we've never needed them in practice so I am removing them from our code even as we speak.)