Skip to content

Conversation

mickael-carl
Copy link

It's not immediately obvious when reading the existing paragraph when variables in nested directories are included or not. This attempts to disambiguate it by explicitly calling out that anything not under main will not be included automatically, and by providing an additional negative example that illustrate exactly this behaviour.

Fixes #2994.

…ted directories

It's not immediately obvious when reading the existing paragraph when
variables in nested directories are included or not. This attempts to
disambiguate it by explicitly calling out that anything not under `main`
will not be included automatically, and by providing an additional
negative example that illustrate exactly this behaviour.

Fixes ansible#2994.
@ansible-documentation-bot ansible-documentation-bot bot added the new_contributor This PR is the first contribution by a new community member. label Oct 4, 2025
@ansible-documentation-bot
Copy link
Contributor

Thanks for your Ansible docs contribution! We talk about Ansible documentation on Matrix at #docs:ansible.im if you ever want to join us and chat about the docs! We meet on Matrix every Tuesday. See the Ansible calendar for meeting details. We welcome additions to our weekly agenda items too. You can add the dawgs-meeting tag to a forum topic to bring it up at the next meeting.

Copy link
Contributor

@s-hertel s-hertel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the example helps. I had a few additional suggestions.

windows/
windows.yml
In this example, no variables are included automatically. Instead, they should be included explicitly (e.g. using the ``vars_from`` in ``import_role`` statements).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In this example, no variables are included automatically. Instead, they should be included explicitly (e.g. using the ``vars_from`` in ``import_role`` statements).
In this example, no variables are included automatically. Instead, they should be included explicitly (for example, using the ``vars_from`` argument in an ``import_role`` task).

windows/
windows.yml
In this example, no variables are included automatically. Instead, they should be included explicitly (e.g. using the ``vars_from`` in ``import_role`` statements).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reporter is using the roles keyword, so I think we should add a note/warning that roles and dependencies cannot configure other entrypoints. (Also related: ansible/ansible#85876)

There's a note in the roles section (below, which links to this section) that says:

vars and defaults can also match to a directory of the same name and Ansible will process all the files contained in that directory. See Role directory structure for more details.

I think it should say "a directory named 'main'", instead.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you clarify that first part? Are you suggesting to add a note that explicitly calls out that for instance vars_from in roles won't work? Basically also fixing ansible/ansible#85876 in this PR?

- Variables from ``vars/`` and ``defaults/`` are imported into play scope unless you disable it via the ``public`` option in ``import_role``/``include_role``.

You can add other YAML files in some directories, but they won't be used by default. They can be included/imported directly or specified when using ``include_role/import_role``.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can ignore or rephrase this suggestion, it's only tangentially related, but I had to read this line multiple times to understand it.

By 'other YAML files' I think it means non-main.yml/main.yaml/main files, and by 'some directories' I think it means tasks/handlers/defaults/vars.

To include files from outside of tasks/defaults/vars directories, include_tasks/import_tasks/include_vars must be used, not include_role/import_role. Handlers just can't be loaded from other directories since there's no mechanism (though an include_tasks handler in a standard location can run tasks from an arbitrary directory).

Suggested change
You can add other YAML files in some directories, but they won't be used by default. They can be included/imported directly or specified when using ``include_role/import_role``.
You can add YAML files named something other than ``main.yml`` in ``tasks/``, ``handlers/``, ``defaults/``, and ``vars/``, but they won't be used by default. They can be specified when using ``include_role``/``import_role``. Note that ``include_role`` and ``import_role`` do not support loading from other directories. You can include tasks/variables from arbitrary locations using ``include_tasks``/``import_tasks``/``include_vars``.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah sorry I didn't necessarily want to refactor this, there were just a bunch of trailing spaces and I figured I might as well remove them. I can definitely rephrase this though if this is something you think would improve this page 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new_contributor This PR is the first contribution by a new community member.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Misleading statement about "defaults" and "vars" sub-folders of roles
2 participants