Summary
jgit-proxy currently loads config from a single file. When multiple sources are stacked (file + git repo + HTTP — see #29), there needs to be a defined strategy for how they are composed into a single GitProxyConfig.
finos/git-proxy supports merge: true (deep merge across all sources) or merge: false (last source wins). Gestalt supports the same pattern via multiple source builders.
Questions to resolve
- Order of precedence — which source wins on conflict? (e.g. local file overrides git repo, or vice versa?)
- Merge granularity — deep merge at the field level, or coarse replace at the top-level key level? (e.g. does a git-sourced
providers list append to or replace the file-sourced one?)
- Validation — is the merged result validated as a whole, or is each source validated independently before merge?
- Error behaviour — if one source fails to load, do we fail the whole reload or proceed with the remaining sources?
Suggested approach
Start with last-source-wins (blunt hammer, no merge) as the default. A single canonical config location is simpler to reason about, easier to audit, and avoids surprising interactions between sources. Merge semantics can be added later if operators need to split config across sources.
Related
Summary
jgit-proxy currently loads config from a single file. When multiple sources are stacked (file + git repo + HTTP — see #29), there needs to be a defined strategy for how they are composed into a single
GitProxyConfig.finos/git-proxy supports
merge: true(deep merge across all sources) ormerge: false(last source wins). Gestalt supports the same pattern via multiple source builders.Questions to resolve
providerslist append to or replace the file-sourced one?)Suggested approach
Start with last-source-wins (blunt hammer, no merge) as the default. A single canonical config location is simpler to reason about, easier to audit, and avoids surprising interactions between sources. Merge semantics can be added later if operators need to split config across sources.
Related