This commit adds some plumbing to allow us to collect metadata
about the caches and spit it out into a json file that we can
then use in the docs to show the predefined caches, capacities
and brief comments about their purpose.
We put that info on the set_lruttl_cache_capacity doc page.
At some point in the past month or two, mkdocs started to fail for
me when docs use `{{since('dev')}}` to reference the install page.
The failure is because we didn't know the correct number of ../
to emit when computing the relative path to the root, because
mkdocs doesn't support absolute paths to other markdown files.
This commit does some grubbing around to try to figure out whether we
are `foo.md` vs. `foo/index.md` because that is the heart of the
problem: both pages would be reported as having `page.url = 'foo/'` but
the markdown links need to consider the file on the filesystem rather
than the effective URL path.
Each time we add a new page in `main`, we get an INFO line like this,
because we didn't know the relative link:
INFO - Doc file 'reference/string/psl_domain.md' contains an absolute link '/userguide/installation/linux/', it was left as is. Did you mean
'../../userguide/installation/linux.md'?
this commit adds some logic to compute the appropriate relative
path and make the doc build a bit less noisy.
This macro allows embedding TOML data into the docs,
and showing it in a tab that has both the TOML and JSON
representation of that data.
It works by executing the toml2jsonc helper that was added
in an earlier commit.
There's some machinery here to compile that utility to run
in the context of the mkdocs docker image; that works
locally, let's see how well it works in CI!
Usage is simple; before:
```toml
["something"]
foo = "bar"
```
after:
{% call toml_data() %}
["something"]
foo = "bar"
{% endcall %}
The first page to get switched over to this is https://docs.kumomta.com/tutorial/configuring_kumomta/
refs: https://github.com/KumoCorp/kumomta/issues/212
The name is passed through to should_enqueue_log_record as an additonal
parameter to make it possible to reason about whether a given record
should get queued for a specific log hook instance.
This is a breaking change, but it can be easily resolved by adding
the name parameter to the `configure_log_hook` call.