mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-12 13:47:01 +00:00
kevinveenbirkenbachandClaude Opus 5
7fd495cdfc
The instructions test held a job of its own that picked one random role per run, so a README's Production block was proven roughly once per 265 roles. The replay now rides on a deploy row instead: no extra runner, and every role the sweep touches gets its documented one-command deploy exercised. The row is the role's smallest variant -- fewest services enabled -- because that is the shape the README describes, and it is chosen among the variants the sweep actually deploys, so a row cut as redundant coverage cannot silently drop the role from the test. A role qualifies only when its README carries a Production block and the guide's own mode is one the role runs and tests. The marked entry carries the guide mode in `instructions` and a 📖 in its job title, between the variant number and a priority ⭐. The guide mode is independent of the mode the rotation gave the row: a swarm row still replays in compose. The step runs last in the deploy job, after the swarm teardown, because the replay deploys the role a second time and needs the runner's ports. call-test-instructions.yml, cli.meta.ci.guide_select and the `instructions` dispatch input go with it. `redundant()` moves next to the marker so the chunker, the plan table and the marker share one definition. The plan table trades its 📊 Weight column for 📖 Instructions; nothing read the weight any more, so it leaves the matrix entries too. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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