Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Work in progress #2

Open
tburghart opened this issue Sep 11, 2024 · 3 comments
Open

Work in progress #2

tburghart opened this issue Sep 11, 2024 · 3 comments

Comments

@tburghart
Copy link
Member

tburghart commented Sep 11, 2024

I've got a working implementation of an update that:

Posting as an issue here for tracking purposes.

@martinsumner
Copy link
Contributor

Something I've been thinking about is about a pipeline for generating configuration references in the docs (in whatever form the docs may be in the future). It would be good in the docs world, if we just had to know what schema files were used and had markdown generated automatically.

For example, if we make rel in riak, as well as produing a riak.conf could it also produce a series of riak_core.schema.md, riak_kv.schema.md, bitcask.schema.md files etc that can be imported easily into the docs.

@martinsumner
Copy link
Contributor

As well as deprecated maybe an {introduced, Msg :: string()} would then be helpful. So when generating configuration docs we can see what version that option/feature was introduced

@tburghart
Copy link
Member Author

tburghart commented Dec 15, 2024

I like the idea of the introduced tag, but that entails work in the doc generator that the deprecated and ignored tags don't - as implemented, they implicitly turn on the hidden flag and cause a warning to be logged when they're encountered in a conf file, so they conveniently avoid any changes to the conf file template generator.

Maybe introduced and some manner of doc generation hook could be a distinct issue, or even two distinct issues? The former would probably not be difficult, the latter would require some serious thinking about how to make the output consumable or at least reference-able with (presumably relative?) path/file#item.key notation.

The implementation for this is essentially complete, it's simply been sidelined at present due to internal priorities. I do hope to get it up onto our branch before very much longer.

@tburghart tburghart reopened this Feb 2, 2025
@tburghart tburghart transferred this issue from OpenRiak/cuttlefish-forked Feb 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants