Files
computer-playbook/plugins
kevinveenbirkenbachandClaude Opus 4.7 c6f4b7fb4b feat(web-app-fediwall): integrate Fediwall as multi-wall public timeline aggregator
New Ansible role rendering one Fediwall instance with one or more
configurable walls under https://fediwall.<DOMAIN_PRIMARY>/<slug>/. Each
wall's `wall-config.json` is forwarded VERBATIM from
meta/services.yml.fediwall.walls[*].config — the YAML there is the
single source of truth, the role's template applies no defaults. Two
matrix-deploy variants ship: variant 0 inherits the services.yml
default (one wall, polls all active Mastodon-API-compatible siblings via
the new `lookup('fediwall_active', ...)` plugin); variant 1 overrides
with two explicitly configured walls (default + mastodon-only) so the
per-wall server scoping is observable end-to-end.

End-to-end Playwright spec drives biber's first OIDC login on Mastodon
and ldapauth-mediated form login on Friendica through the same web UI a
human would use — biber's local accounts come into existence lazily on
first SSO login, exactly as in production. The cross-Fediverse test is
data-driven against each wall's `wall-config.json.servers`: a sibling's
post is visible iff its host is listed there.

Cross-cutting fixes that surfaced during the iteration ship alongside:

- utils/cache + utils/templating: type-preserving render path for
  single-Jinja-expression scalars in `lookup('config', ...)`.
  `_templar_render_best_effort` always coerced its output to `str`, so a
  list-returning lookup like `{{ lookup('fediwall_active', 'domains') }}`
  collapsed to its Python repr. `_render_scalar` now detects the
  `{{ ... }}`-only shape and routes it through the new
  `_templar_render_preserve_type` helper, which returns templar's
  native value (list/dict/etc.) instead of stringifying.

- web-app-friendica/tasks/04_addons.yml: force a `disable` + `enable`
  cycle for enabled addons. Friendica's `addon enable` only fires the
  `_install` hooks on the disabled→enabled transition, so an
  already-enabled-but-broken state (the addon shows up in `list
  enabled` but its `_install`-registered hooks are missing from the
  `hook` DB table) silently rejected every ldapauth login at runtime.
  Cycling through disable+enable reliably re-registers the hooks.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-05 19:50:05 +02:00
..
…

🧩 Ansible Plugins (plugins/)

This document is the central reference for plugin types and plugin placement in Infinito.Nexus.

🗂️ Current Project Layout

plugins/
├── action/   # custom action plugins
├── filter/   # custom Jinja2 filters
└── lookup/   # custom lookup plugins

Configured plugin paths in this repository are defined in ansible.cfg:

  • action_plugins = ./plugins/action
  • filter_plugins = ./plugins/filter
  • lookup_plugins = ./plugins/lookup

📚 All Common Ansible Plugin Types

The table below summarizes common Ansible plugin types and their conventional directory names.

Emoji Plugin Type Conventional Directory Purpose
⚙️ action action_plugins/ or plugins/action/ Wrap/extend module execution behavior at task runtime.
🔐 become become_plugins/ Implement privilege escalation methods.
💾 cache cache_plugins/ Persist gathered facts and cached data between runs.
📣 callback callback_plugins/ React to play/task events (logging, reporting, notifications).
🖧 cliconf cliconf_plugins/ Define CLI command transport behavior (mainly network platforms).
🔌 connection connection_plugins/ Control how Ansible connects to targets (ssh, local, etc.).
🔍 filter filter_plugins/ or plugins/filter/ Add Jinja2 filters for data transformation.
🌐 httpapi httpapi_plugins/ API transport layer over HTTP(S), mainly for network devices.
🧭 inventory inventory_plugins/ Build dynamic inventories from APIs, services, or files.
👉 lookup lookup_plugins/ or plugins/lookup/ Resolve dynamic values during playbook processing.
🛰️ netconf netconf_plugins/ NETCONF transport integration for network automation.
🐚 shell shell_plugins/ Adjust shell command wrapping/execution behavior.
🧠 strategy strategy_plugins/ Customize task scheduling/execution strategy.
✅ test test_plugins/ Add Jinja2 tests used in conditions and templates.
📦 vars vars_plugins/ Load variables from custom sources.

🧭 Which Plugin Type to Use

⚙️ action

Use when task execution behavior itself must be changed or wrapped.

Examples:

  • centralized retry logic (uri_retry.py),
  • argument normalization before module dispatch,
  • pre/post task orchestration.

🔍 filter

Use for pure data transformation in Jinja2 expressions.

Examples:

  • mapping/normalizing dictionaries,
  • deriving computed fields for templates,
  • deterministic formatting helpers.

👉 lookup

Use when a value must be dynamically resolved at runtime.

Examples:

  • computing IDs from role metadata,
  • resolving paths/version data,
  • reading structured project data for templates/tasks.

📣 callback

Use to hook into execution events and shape output/reporting.

🧭 inventory

Use when host/group data should come from a dynamic source.

🧠 strategy

Use to alter how tasks are scheduled/executed across hosts.

📦 vars

Use to load variables from custom backends.

🔌🔐🐚 connection, become, shell

Use to customize low-level execution and privilege mechanics.

💾 cache

Use to persist facts/results across runs for performance and consistency.

🖧🌐🛰️ cliconf, httpapi, netconf

Use in network automation contexts requiring protocol-specific transport behavior.

✅ test

Use to add custom Jinja2 test operators for conditional logic.

🧪 Best Practices

  • Keep plugin interfaces explicit and stable.
  • Keep plugin logic focused; move shared logic to utils/.
  • Add unit tests for plugin behavior and integration tests for end-to-end flows.
  • Prefer deterministic outputs and avoid hidden global state.
  • Document any plugin-specific task arguments in the plugin docstring and README.

🔗 References