mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 19:01:54 +00:00
kevinveenbirkenbach
fb977e975a
The swarm-compat lints (`compose-chdir-in-task`, `compose-verb-in-task`, `docker-compose-raw-call`) currently flag every offending line and only accept per-line / file-head `# nocheck:` markers. That is noisy for two patterns that are objectively safe: 1. Tasks gated by `when: DEPLOYMENT_MODE \!= 'swarm'` (or `== 'compose'`) never reach a swarm host - the compose verbs inside are legitimate. 2. YAML comment lines, handler-trigger list items, and human-readable metadata fields (`name:`, `msg:`, `title:`, `label:`, `description:`) contain the word `compose` as documentation, not as a shell call. The lints now skip both classes automatically. - utils/annotations/task_gate.py: new helper `is_task_compose_only_gated(lines, idx)`. Walks the surrounding task block via a line-based heuristic and matches `when:` against the compose-only DEPLOYMENT_MODE expressions. Documented as deliberately shallow (no YAML parse). - tests/lint/ansible/shell/test_no_compose_chdir_in_shell_tasks.py and tests/lint/ansible/shell/test_no_compose_verb_in_shell_tasks.py: add a file-level `is_suppressed_in_head` skip, the `is_task_compose_only_gated` skip, and -- for the verb lint -- three extra regex exclusions for notify-list items, YAML metadata fields, and quoted list items. - tests/lint/ansible/shell/test_no_docker_compose_raw_call.py: skip YAML comment lines (bluesky and jenkins each had a `# … docker compose build …` doc-comment that was being flagged as a real call). - tests/unit/utils/annotations/test_task_gate.py: 21 cases covering block-bounds + gate detection, including a `TestKnownLimitations` class that pins the heuristic's blind spots (folded-scalar `when:`, list-form `when:`, `in`/`not in`, unquoted literal, outer-`when:` inheritance into `block:` children) so a future YAML-aware refactor knows exactly which assertions to flip.
Shared Utilities (utils/)
This directory contains shared Python helpers used by custom modules and plugins.
Purpose
Use utils/ for reusable code that should not be duplicated across:
library/modules,plugins/action/,plugins/filter/,plugins/lookup/.
Typical shared utilities:
- API clients,
- validation/conversion helpers,
- path and configuration helpers,
- cross-plugin/module domain logic.
- Shared HTTP(S) connection handler for multiple modules.
- Common validation or transformation functions for user input.
- Utility functions for interacting with Docker, LDAP, etc.
- Grouped helper packages such as
utils/domains/for related domain logic.
Design Guidelines
- Keep helpers focused and composable.
- Avoid side effects during import.
- Prefer explicit function/class APIs over implicit globals.
- Keep dependencies minimal so modules/plugins stay lightweight.
Example Import
from utils.domains.primary_domain import get_primary_domain
What Does Not Belong Here
- Standalone executable modules (put in
library/). - Ansible plugin entrypoints (put in
plugins/*).
References
- Module utilities: https://docs.ansible.com/ansible/latest/dev_guide/developing_module_utilities.html
- Plugin development: https://docs.ansible.com/ansible/latest/dev_guide/developing_plugins.html