Rainer Gerhards ed91aebc42 devtools: fold local review experiment into planner
Why:
The old AI local-review workflow was experimental, duplicated newer
validation guidance, and still carried stale review behavior on main.

Impact:
Local validation keeps useful checks in the maintained planner and
removes the obsolete experiment while retaining shared prompt assets.

Before/After:
Before, local review policy lived partly in an unused AI script and a
deleted workflow entry point. After, the planner and skills own the
reusable checks and prompt guidance.

Technical Overview:
Remove ai/local-review-workflow.sh and .agent/workflows/audit.md.
Teach devtools/local-validation-plan.sh to derive its default base from
RSYSLOG_LOCAL_VALIDATION_BASE, rsyslog.localValidationBase, or the
worktree HEAD reflog baseline.
Use the same base for local Cubic review so committed branch changes are
reviewed against the worktree creation point.
Add advisory raw allocation and test antipattern scans, and run fast mock
distcheck for distribution-risk test/build changes.
Fold the old audit prompt guidance into the local container testing skill
as late manual prompt audits without launching another AI CLI.
Document ai/ as the central shared prompt-asset library and remove stale
references to deleted workflow paths.

With the help of AI-Agents: OpenAI Codex
2026-06-02 10:15:24 +02:00

5.4 KiB
Raw Permalink Blame History

name, description
name description
rsyslog_commit Ensures compliance with rsyslog's strict commit message and branching policies.

rsyslog_commit

This skill standardizes the final step of the development workflow: committing and contributing.

Quick Start

  1. Format First: For C/H changes, agents MUST run devtools/format-code.sh --git-changed to rewrite formatting when needed.
  2. Commit Message: Follow the 62/72 rule and the mandatory "Why" structure.
  3. Attribution: Include the AI-Agent footer.

Detailed Instructions

1. Pre-Commit Checklist

  • Code Style: Agents MUST run devtools/format-code.sh --git-changed if any .c or .h files were modified and formatting may need to be applied. This is mandatory for C source changes before commit. For a read-only local validation gate, agents MUST run devtools/format-code.sh --git-changed --check --check-if-available; this skips with a warning if the exact configured clang-format executable is not installed. CI will not pass with improperly formatted C/H code; a missing local formatter is only a local tooling limitation, not permission to skip formatting.
  • Python Style: If Python files changed and pycodestyle is installed, run devtools/format-python.sh <changed-python-files>. Use devtools/format-python.sh --fix <changed-python-files> only when you intentionally want autopep8 rewrites. If the tools are missing, suggest installing them (sudo apt-get install -y pycodestyle python3-autopep8 on Debian/Ubuntu) but do not block unrelated build or test validation. The shared 120-column style configuration lives in setup.cfg; review autopep8 output carefully for legacy Python-2-style scripts.
  • Local Preflight Linters: Before heavier validation or opening/updating a PR, run useful diff-scoped linters when installed: shellcheck for changed *.sh, checkbashisms -p for changed scripts that claim POSIX sh portability, devtools/format-python.sh --check-if-available for changed Python, actionlint and pinned zizmor for changed workflows, hadolint for changed Dockerfiles, trivy config for changed infrastructure/config files, and jscpd for larger changed source/test sets. Guard optional commands with command -v; if a tool is missing, suggest installing it but do not block unrelated build or test validation. On Debian/Ubuntu, checkbashisms is provided by devscripts. Do not run cppcheck routinely unless requested; it is too noisy for the rsyslog tree.
  • Validation: Ensure the relevant build/test path passed. For PR-ready implementation work, prefer the local container-testing skill's change-gated validation over unconditional full-suite local runs.
    • Late Prompt Audits: For non-trivial C/H, concurrency, or test/build plumbing changes, follow the local container-testing skill's late prompt-audit stage. Read and apply the project's canned prompts directly; do not launch another AI CLI from repository scripts.
    • Local Cubic: Run local Cubic review for code changes when cubic is installed and reachable. Skip Cubic for documentation-only changes. For tests, workflows, build tooling, and mixed changes, use Cubic when the change is non-trivial, behavior-affecting, security-sensitive, or large. Hosted Cubic/Gemini PR comments are additional review feedback, not a substitute for local Cubic where local Cubic applies.
    • Container Gate: For implementation changes, run the rsyslog_local_container_testing skill's PR-ready change-gated local container sequence when container tooling is available. Focused run-ci.sh TEST=... commands are targeted container tests, not PR-ready local container validation unless that skill explicitly permits the reduced lane.
    • Mock Smoke Check: If you added or renamed test files, run make distcheck TEST_RUN_TYPE=MOCK-OK -j$(nproc) as a final distribution check.
    • Note: If you already successfully built and tested your changes immediately before formatting, you do NOT need to re-run the build/test cycle. Formatting is a normalization step and does not affect functionality. A read-only formatting check is already part of the deterministic local validation helper for changed C/H files.

2. Commit Message Structure

Rsyslog requires rich, structured commit messages (plain ASCII).

  • Title: <component>: <action> (Max 62 characters).
  • Body: Max 72 characters per line.
  • GitHub Issues: Use full URLs (e.g., https://github.com/rsyslog/rsyslog/issues/883) instead of shorthand #883.
  • Mandatory Sections:
    • Why: Brief non-technical rationale.
    • Impact: One line if behavior/tests changed.
    • Before/After: One-line summary.
    • Technical Overview: 412 lines describing the change conceptually.
  • AI Footer: With the help of AI-Agents: <agent-name>

3. Using the Assistant

4. Branching & PRs

  • Base Branch: Always target main.
  • Naming: i-<issue-number> or <agent-name>-i-<issue-number>.
  • Target: PRs must target rsyslog/rsyslog directly.
  • rsyslog_build: To verify the code before committing.
  • rsyslog_test: To provide validation metrics for the commit message.