Files
computer-playbook/plugins/filter
kevinveenbirkenbachandClaude Opus 5 044c511394 fix(magento): resolve volume mountpoint at runtime
Both creates: guards pointed at paths that could never match, so the
bootstrap and setup:install shells re-ran on every deploy.

The first guard went through docker_volume_path, which hardcodes
/var/lib/docker/volumes/<name>/_data and misses any relocated docker
data-root. The second was worse: path_join over the bare volume name
produced a relative path, resolved against the Ansible working
directory, which matched nowhere at all.

Both now derive from the mountpoint the daemon reports. The stack-host
gate moves to a single include, mirroring web-app-akaunting.

With its last caller converted, docker_volume_path is deleted. It could
not be repaired: a Jinja filter runs on the controller and cannot know a
remote host's data-root.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-06 10:47:38 +02:00
..

Custom Filter Plugins for Infinito.Nexus

This directory contains custom Ansible filter plugins used within the Infinito.Nexus project.

When to Use a Filter Plugin

  • Transform values: Use filters to transform, extract, reformat, or compute values from existing variables or facts.
  • Inline data manipulation: Filters are designed for inline use in Jinja2 expressions (in templates, tasks, vars, etc.).
  • No external lookups: Filters only operate on data you explicitly pass to them and cannot access external files, the Ansible inventory, or runtime context.

Examples

{{ role_name | get_entity_name }}
{{ my_list | unique }}
{{ user_email | regex_replace('^(.+)@.*$', '\\1') }}

When not to Use a Filter Plugin

  • If you need to load data from an external source (e.g., file, environment, API), use a lookup plugin instead.
  • If your logic requires access to inventory, facts, or host-level information that is not passed as a parameter.

Further Reading