Problem
Handler defaults and help texts live in a static YAML inside the oxygen package, so keeping bakery fields in robotmk_bridge_plugin_bakery.py in sync is error-prone.
The bakery module itself cannot import oxygen at runtime on the Checkmk server because the package is not available there.
Goal
Let each handler expose its defaults via the parse_results signature (default args) and its inline help via the docstring.
Generate the bakery rule definitions automatically from that metadata so the fields stay consistent.
Suggested approach
Add a helper script (e.g. tools/generate_bakery_spec.py) that imports the available oxygen handlers, introspects parse_results via inspect.signature, and extracts parameter defaults plus docstring text.
Feed that metadata into a template (Jinja or similar) to emit robotmk_bridge_plugin_bakery.py. Keep a lightweight scaffold checked in so the generated module slots into the existing WATO registration.
Run the generator during packaging (e.g. part of release.sh or a dedicated Make/Invoke/Tox task) to ensure the bakery file is up to date before shipping. Optionally add a CI check to confirm the file matches the generated output.
Document the workflow in DEVELOPMENT.md, including how to run the generator locally when adding or changing handlers.
Open questions
- How should handlers register themselves so the generator can discover them (entry points vs. importable registry)?
- Where should handler docstrings live if they need localization or richer formatting?
Acceptance criteria
- [] The bakery file is generated from handler metadata without manual edits.
- [] Handler defaults documented via parse_results translate into correct field defaults in Checkmk.
- [] Handler docstrings surface as field help text.
- [] Build tooling guarantees the bakery module is regenerated when handler metadata changes.
Problem
Handler defaults and help texts live in a static YAML inside the oxygen package, so keeping bakery fields in robotmk_bridge_plugin_bakery.py in sync is error-prone.
The bakery module itself cannot import oxygen at runtime on the Checkmk server because the package is not available there.
Goal
Let each handler expose its defaults via the parse_results signature (default args) and its inline help via the docstring.
Generate the bakery rule definitions automatically from that metadata so the fields stay consistent.
Suggested approach
Add a helper script (e.g. tools/generate_bakery_spec.py) that imports the available oxygen handlers, introspects parse_results via inspect.signature, and extracts parameter defaults plus docstring text.
Feed that metadata into a template (Jinja or similar) to emit robotmk_bridge_plugin_bakery.py. Keep a lightweight scaffold checked in so the generated module slots into the existing WATO registration.
Run the generator during packaging (e.g. part of release.sh or a dedicated Make/Invoke/Tox task) to ensure the bakery file is up to date before shipping. Optionally add a CI check to confirm the file matches the generated output.
Document the workflow in DEVELOPMENT.md, including how to run the generator locally when adding or changing handlers.
Open questions
Acceptance criteria