I dont know if it should be a bug or an enhancement, but when we are already telling config server to find configurations under a particular folder using following key : spring.cloud.config.server.git.search-paths=

then why does config server checkout the entire git repository, and doesn't do sparse checkout of only that particular folder in the repository.

Because for my project it results in lack of performance when it tries to fetch the results as it has to see changes in entire project, which is very huge in my case. (don't forget the time taken by first time checkout )

Comment From: spencergibb

Have you tried spring.cloud.config.server.git.refresh-rate?

From https://cloud.spring.io/spring-cloud-static/Greenwich.RELEASE/single/spring-cloud.html#_appendix_compendium_of_configuration_properties

Time (in seconds) between refresh of the git repository

Comment From: Swatikp

Yes I am already using spring.cloud.config.server.git.refresh-rate property in my config server. But the thing is, the project I am working in is a huge project and has a 120 MB repository size in github, and in which there is one folder named config which contains the configurations (which i have given in search-paths). I know Github already provides a provision to checkout certain folders from a huge project, which is called sparse checkout. My question is, if we already know that config server has to pick up properties only from our given folder, why cannot we combine Github sparse checkout feature in Spring cloud config server to make the process of refresh faster.

Comment From: spencergibb

Config servers git integration does not have that functionality. Our recommendation is to isolate configuration in separate repositories. I'm going to mark this as waiting for votes.

Comment From: rudolfv

@spencergibb This will also be useful feature for us. We would like to use something like the following:

git:
  uri: ssh://myuser@bitbucket.acme.com:7999/myapps/{application}.git
  searchPaths: 'src/main/resources'

This will allow us to have config/{label} branches that are created off a specific application version tag, altering some of the configuration properties.

I know it doesn't follow your recommended approach, but we've tried that and this is a better fit for what we want to achieve.

Or would you describe this as an anti-pattern?

I would suggest adding support for both sparse checkouts and single branches. I could look into submitting a PR if you can point me in the general direction of where the changes would be required.

Comment From: ghost

@spencergibb Any development on this possible enhancement? We are looking for something similar with sparse clone from Gitlab.

Comment From: spencergibb

@i-at-github no, you will see changes in labels, projects, and milestones assigned when there is. I don't know if this is even possible with jgit.