Is your feature request related to a problem? Please describe. I get frustrated by bad configurations both syntactically bad (malformed ymls) and against my teams standards (like naming application names too long). It's even worse when these things are only apparent at runtime.
Describe the solution you'd like I propose another module in this project that houses a cli application that can take my config server's configuration and then runs a set of lint rules. Some rules could be blessed in the open-source project and we could expose this framework such that I can add additional rules based on my team's standards.
Sometimes the lint can be done statically against the files in git but other times I want to render the environment config against a profile which is why I want the scc integration.
Describe alternatives you've considered We could just leave this to users to build their own bespoke solution (like I have) but I have seen this come up before in an old talk 44:10 where Clint mentions a yml validation gradle task.
Additional context Way back I wanted this only because I couldn't figure out what was broken in my yml (turned out to be dupe keys).
Comment From: spencergibb
I'm not sure this is something we want to tackle. Configuration can be in properties or yaml. There's another open issue about not applying a new environment during refresh if standard boot config props validation failed, which I think is more in scope.
Comment From: spencergibb
I also think it's a process issue. If the first time you are applying particular configuration is in production, there's something missing.
Comment From: nhomble
Most of the time I agree @spencergibb about applying a config in nonprod first, but sometimes configurations are profiled to only be used in production. For example, if I have a configuration for my email domain, I may use junk config in nonprod but only want to take the reputational hit in a production environment.
Standard config property validations seem right to me. The gap I see there are errors in the configuration that causes the config server to fail to serve the configuration in the first place.
I also see what you mean about config being properties or yml. We are able to lint yml changes on the git backend pretty easily on each pr. Testing against the full property set is more of an integration test considering the different backends like vault we'd have hooked up. I guess I'd be interested to know if other teams consistently come up with their own linters and see if there is an opportunity for consolidation.
Comment From: spencergibb
I don't know of anyone else doing linters besides what you mentioned. For now, I'm going to close this after some discussion with the team as we do not want to support it.
Comment From: nhomble
Totally understand, thanks for taking the time!