Create an environment that stores default relative paths for role templates/files #3

Closed
opened 2025-12-16 16:34:35 +00:00 by admin · 3 comments
Owner

It would be ideal to define some variables for the execution environment of our Ansible playbooks and roles, that define the expected relative paths within $SKATO_ANSIBLE_ROOT/roles/*/{templates,files}/ for finding specific kinds of configuration files or data necessary for role tasks/handlers or Ansible plays.

A possibility is storing these paths in a .env file under $SKATO_ANSIBLE_ROOT/, that is sourced by the shell and contains, e.g.:

# $SKATO_ANSIBLE_ROOT/.env
SKANSIBLE_SSH="sshd_config.d"

Then, the hard-coded paths to the Ansible role templates or files in tasks or handlers that use the community.general.copy or community.general.template Ansible modules will be replaced with paths that make use of, i.e. incorporate, these environment variables.

This would allow the user of these Ansible roles / plays to change the directory structure within which certain things are found, without breaking the working code.

This is just an example implementation--there may be better ways or ways that actually work (there is no guarantee that placing environment variables in Ansible YAML files will actually have them be evaluated by the local shell--would need to some research to know).

It would be ideal to define some variables for the execution environment of our Ansible playbooks and roles, that define the expected relative paths within `$SKATO_ANSIBLE_ROOT/roles/*/{templates,files}/` for finding specific kinds of configuration files or data necessary for role tasks/handlers or Ansible plays. A possibility is storing these paths in a `.env` file under `$SKATO_ANSIBLE_ROOT/`, that is sourced by the shell and contains, e.g.: ```bash # $SKATO_ANSIBLE_ROOT/.env SKANSIBLE_SSH="sshd_config.d" ``` Then, the hard-coded paths to the Ansible role templates or files in tasks or handlers that use the `community.general.copy` or `community.general.template` Ansible modules will be replaced with paths that make use of, i.e. incorporate, these environment variables. This would allow the user of these Ansible roles / plays to change the directory structure within which certain things are found, without breaking the working code. This is just an example implementation--there may be better ways or ways that actually work (there is no guarantee that placing environment variables in Ansible YAML files will actually have them be evaluated by the local shell--would need to some research to know).
admin added this to the optimal soft-coding milestone 2025-12-16 16:34:35 +00:00
admin added the qol/feature label 2025-12-16 16:34:35 +00:00
admin self-assigned this 2025-12-16 16:34:35 +00:00
admin added this to the skato-ansible feature release project 2025-12-16 16:34:35 +00:00
admin moved this to To Do in skato-ansible feature release on 2025-12-16 17:06:00 +00:00
Author
Owner

Apparently, the Ansible documentation mentions a lookup Jinja/Python function plugin, ansible.builtin.env on this page: https://docs.ansible.com/projects/ansible/latest/collections/ansible/builtin/env_lookup.html

This may be useful for implementing an execution environment containing the relative paths of role templates/files.

Apparently, the [Ansible documentation](https://docs.ansible.com) mentions a `lookup` Jinja/Python function plugin, `ansible.builtin.env` [on this page](https://docs.ansible.com/projects/ansible/latest/collections/ansible/builtin/env_lookup.html): https://docs.ansible.com/projects/ansible/latest/collections/ansible/builtin/env_lookup.html This may be useful for implementing an execution environment containing the relative paths of role templates/files.
admin added the fix/usability_bug label 2025-12-16 17:43:29 +00:00
admin moved this to In Progress in skato-ansible feature release on 2025-12-16 18:41:04 +00:00
Author
Owner

Created a script recently that also exports environment variables for paths relevant to skato-ansible project: .bin/skansible.sh

That said, this doesn't really allow use of ansible.builtin.env for lookup Jinja/Python function plugin as mentioned previously, at least until after the ${SKATO_ANSIBLE_ROOT}/.bin/skansible.sh has been executed. This can be ensured by requiring the user use that script to interface with ansible-playbook, ansible-vault, and ansible-galaxy via its native functions, rather than calling those commands directly in the shell.

Given the need to manipulate certain parts of our YAML files when updating, for example, the GPG keys of/for certain users created or to be created by our Ansible playbooks (or our Ansible bootstrap role), among other things, it might be best to transition to implementing a CLI tool using the Python Click package/library.

Important

Only start using environment variable lookups in Ansible when CLI for Ansible commands and other related commands for manipulating the Ansible YAML has been built.

Created a script recently that also exports environment variables for paths relevant to `skato-ansible` project: [.bin/skansible.sh](https://git.sukaato.moe/admin/skato-ansible/src/commit/ffa5408e9c01e6c721d012ab0b48d32ec5609308/.bin/skansible.sh#L4) That said, this doesn't really allow use of `ansible.builtin.env` for `lookup` Jinja/Python function plugin [as mentioned previously](https://git.sukaato.moe/admin/skato-ansible/issues/3#issuecomment-29), at least until after the `${SKATO_ANSIBLE_ROOT}/.bin/skansible.sh` has been executed. This can be ensured by requiring the user use that script to interface with `ansible-playbook`, `ansible-vault`, and `ansible-galaxy` via its native functions, rather than calling those commands directly in the shell. Given the need to manipulate certain parts of our YAML files when updating, for example, the GPG keys of/for certain users created or to be created by our Ansible playbooks (or our Ansible `bootstrap` role), among other things, it might be best to transition to implementing a CLI tool using the [Python Click package/library](). > [!important] > Only start using environment variable lookups in Ansible when CLI for Ansible commands and other related commands for manipulating the Ansible YAML has been built.
Author
Owner

Decided on creating a Python app that handles interface with the environment. An INI file may be used but may otherwise be unnecessary for path variables in particular, as they can be defined in or for relevant classes for or in the Python app itself. This means maintaining consistency where needed when attempting changes or additions will not be a burden for the user, but will be handled "programmatically."

Decided on creating a Python app that handles interface with the environment. An INI file may be used but may otherwise be unnecessary for path variables in particular, as they can be defined in or for relevant classes for or in the Python app itself. This means maintaining consistency where needed when attempting changes or additions will not be a burden for the user, but will be handled "programmatically."
admin closed this issue 2026-01-02 21:49:25 +00:00
admin moved this to Done in skato-ansible feature release on 2026-01-02 21:54:04 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: admin/skato-ansible#3