On startup the JGitEnvironmentRepository deletes the configured baseDir and then attemps to pull a fresh config from the remote Git server.
This operation gives us a point of failure intra-day when we have to restart the config server and our Git repo is down.
Is there a reason (or reasons) why we couldn't have a flag on the delete functionality that would skip the baseDir deletion and if the remote repo wasnt available, then we would log a warning (ideally update a health actuator value), but serve up whatever config was stored locally on disk (from the local git repo copy that we retrieved previously). Taking this approach would allow all our dependent services to continue running and obtaining a known configuration until such time as the remote repo is available again and then the config servers could all re-sync the latest configuration. In our specific situation, the git repo we run is not maintained to the same level of intra-day SLA as our live applications - being able to read configs from the local git copy seems like a good win for reliability (coupled with the alert/health endpoint). But perhaps there are reasons we dont understand why this cant/shouldnt be done :-)
( Im thinking some boolean flag inside of deleteBaseDirIfExists would accommodate this )
Comment From: ryanjbaxter
I think this is the same issue https://github.com/spring-cloud/spring-cloud-config/issues/1928