rsyslog/tools/AGENTS.md
Rainer Gerhards b8d8faa68c docs: add agent guides and module metadata scaffolding
Improve AI-facing documentation to speed up contributor onboarding after
the gpt5-codex agent update. The guides clarify bootstrap, testing, and
where to find module ownership so agents can work predictably and avoid
expensive CI-only paths.

Impact: documentation-only; no runtime changes. Clarifies when to use
direct test scripts vs. the autotools harness.

This introduces repository-wide AGENTS guides (root, plugins/, contrib/,
tools/, doc/) plus module-focused guides for omelasticsearch, imkafka,
omkafka, and omruleset. It adds metadata templates for core and contrib
modules, initial MODULE_METADATA.yaml files for the Kafka and ES modules,
and a tools/MODULE_METADATA.json for built-ins. The top-level guide now
includes quick links, “priming a fresh AI session,” and explicit
autotools bootstrap instructions (run ./autogen.sh when autotools inputs
change). Testing guidance asks agents to prefer invoking ./tests/*.sh
directly, reserving `make check` for CI reproductions. The doc subtree
gains its own AGENTS.md and an AI doc-builder base prompt to keep edits
consistent. doc/ai/module_map.yaml was annotated to reference per-module
metadata.

Before: scattered or missing agent guidance; unclear when to bootstrap
autotools or run the full harness. After: structured, discoverable docs,
templates, and metadata that align contributor workflow across modules.
2025-09-26 13:00:06 +02:00

1.5 KiB
Raw Blame History

AGENTS.md Built-in tool modules

The tools/ directory holds historic built-in modules that share code with the core but are compiled directly into the rsyslog binary:

  • omfile.c
  • omusrmsg.c
  • omfwd.c
  • ompipe.c
  • omshell.c
  • omdiscard.c

Build & testing expectations

  • These modules are always built as part of the default configuration; no additional ./configure flags are required.
  • Follow the top-level build workflow: run ./autogen.sh only when autotools inputs change, configure with the options your change requires, and rebuild via make.
  • There are no standalone regression scripts for these built-in modules. When modifying them, rely on targeted configuration tests under tests/ (e.g. ./tests/omfile-basic.sh) or add new ones as needed.

Metadata

  • Shared metadata lives in tools/MODULE_METADATA.json so we do not duplicate YAML files beside each source.
  • Keep the JSON array sorted by module name and update the last_reviewed field whenever support status, maturity, or contacts change.
  • The default primary_contact points at the rsyslog GitHub Discussions and Issues queue; replace it with a specific maintainer only when a new owner is explicitly assigned.

Documentation touchpoints

  • Most of these modules have reference guides under doc/source/configuration/modules/. Update the relevant .rst files when you change defaults or add features.
  • Cross-reference changes in doc/ai/module_map.yaml if the concurrency or locking guidance shifts.