Validate that the secrets and config required by the schema exactly match defined secrets

[alecthomas]

Error for missing entries, and warn for entries that are defined but not required?

- [ ] Adding secrets/configs validates against the list of modules defined in the ftl-project.toml file - quick scan to just load the ftl.toml and cross-check - [ ] Add a `--force, -f` flag to override this check - [ ] Then a future PR to improve schema validation - [ ] Error if a module references a config/secret that is not defined - [ ] Warn if a config/secret is defined but is not used

^^ this is likely all wrong

[wesbillman]

@deniseli This is probably a good issue to take a look at since you're working in the ftl-project world now. (cc: @worstell)

[deniseli]

Does this all sound right?

• ftl config set should warn if the value being added is not referenced in any modules yet.
• ftl config unset should fail if the value being removed is still referenced in a module, unless --force or -f is present, in which case we should warn instead of erroring.
• The force flag shorthand should be -f, not -F.
• The 3 commands dev, build, and deploy (which call instantiate a new buildengine) should all log warnings (for unnecessary configs/secrets) and errors (for configs/secrets required but not provided).

[alecthomas]

I don't think 1 is necessary, it will be true most of the time. I think most of the validation should be done at schema validation/build time.

[deniseli]

Perfect, I'll plan to build everything except the first thing. Thanks!

[alecthomas]

Let's defer this until we have all the changes (eg. #1473, #1545, #1548) around secret management merged in. I think the solution to this will become clearer at that point. My suspicion is that we'll end up validating this when a deployment is pushed to the controller.

[matt2e]

Maybe this is going to be solved with this one then: #1906