Is your feature request related to a problem? Please describe. I want to use the refreshRate property for 2 reasons: * keep load on our bitbucket server low (it's provided externally and unfortunately they don't seem to like a lot of requests) * improve performance for clients (as we don't have to go back and forth to bitbucket every request but only once every x minutes)

Unfortunately, there are also scenario's where you need an immediate refresh. Specifically, we have cicd pipelines that push a new tag to the config repo, and right after that a pod is spun up which will try to fetch that specific config.

Describe the solution you'd like Possible solutions: * Change the refresh logic, such that when you are inside the refreshRate window, but a tag or branch is not available in the cloned repo, it tries to update from the remote anyway (this might result in pretty obfuscated behavior, not sure I like this) * Include a parameter on the endpoint to force update of the repository. If you request a config with that parameter ?force-update=true, spring-cloud-config-server should always.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. * I've looked into using sping-cloud-config-monitor, however, as I understand it this will only send a notification to any connected clients that there updates, it will not refresh the repo. I may be wrong here. If I'm right, this does make me wonder how this feature works together with the refreshRate setting at all; wouldn't the client then on refresh still potentially get the old config?

Comment From: ryanjbaxter

Correct it just sends a notification to the client that its configuration has changed, it does not tell the server.

I am not sure I like option 2 where the client can override the server behavior. That would mean anyone could make a request to the server causing it to make a request to the git server.

You make a good point that it would be great if there was a webhook for the server, so the server knows a git repo it is using has changed and it could expire the refresh rate.

Comment From: horvatkevin

I've just spent a couple hours debugging and troubleshooting the config server as it wasn't refreshing the server-side git repository, upon receiving a WebHook request from GitLab.

What's the use case of the /monitor endpoint, considering the official docs explicitly mention SCM WebHooks as an example, when there's no chance that config clients are ever able to obtain the latest SCM-hosted configuration?

I'm willing to help implement a solution as this is a feature that I would really like to have. As far as I can tell, there are likely two things that need to be tackled:

  1. The config monitor needs a way to tell the config server to reload the configured EnvironmentRepository instances and wait for their feedback, before dispatching any refresh events to the Cloud Bus.
  2. The currently present EnvironmentRepository implementations would have to be extended to support refreshing, even when their regular timed refresh interval hasn't expired yet.

Would this be a strategy that you'd be aligned with, or would you recommend another approach?