Closed michaelweiser closed 2 years ago
I looked into whether the reset syntax could be streamlined to remove the need for the dash as distinguisher like so:
[section]
option: -
option.1: value1
Apart from actually not liking this syntax because it visally decouples the reset from the list building, it threw up a problem if a user were to put a reset as the very first action in a main config file. In that case we'd need to know in our interpolation that this option was intended to be a list instead of just a normal option with a (legitimate) dash as value. Due to my new-found dislike for the syntax stopped digging there.
I also added an additional test and note in ruleset.conf.sample
highlighting the (somewhat unexpected even to myself) fact that list items with identical identifiers/distinguishers in different files do not replace each others values.
Rebased and force-pushed only to get a fresh opinion from CI. No changes.
Add functionality to load additional drop-in config snippets from a directory ending in .d next to the main configuration file. This allows to separate a distributed default config from local changes. Drop files have to be named using leading double digits and a trailing .conf by default. The former allows for lexicographical sorting determining the order in which the snippets are read and option values overwrite each other.
Two new global options allow customisation of the drop file directory template and drop file globbing pattern. The test suite and main config file sample are extended to match.
Because the logic is implemented in PeekabooConfigParser, it works with all config files, not only the main peekaboo.conf.
Closes #69.
This logic is meant to simplify our installer, docker compose and k8s use-cases as well. Respective PRs to follow.