presence of tasks_from in roles should raise linting error

[ssbarnea]

Issue Type

• Feature request

Desired Behaviour

Doing tasks_from when you import a role is high likely to be a design-mistake (anti-pattern) because it means that it will bypass the main entry-point of the role: tasks/main.yml. When role grow their maintainers will start splitting tasks into multiple file, but this does not mean that they are supposed to be called by outside.

Ansible has no way to document which tasks files are private or not and getting failures because you did run some tasks that were only written with the assumption that they are included from another file is a recipe for delayed failure.

For this reason, I propose that tasks_from should be discouraged and allow people to use it only when they manually disable it locally via a # noqa comment.

Using tasks_from is like calling private methods on functions, they may or may not work now, but we all know that is a bad practice. Even if it may work today, a minor update of the role is likely to break them.

Role developers should be careful to control execution of the role via documented variables that are passed to the role.

Valid use cases for tasks_from

When writing tests for your role (like writing molecule tests), it is ok to use tasks_from to test specific areas of the role. That is ok because the testing code is part of the role itself and any refactoring can be done by updating the tests too. Still, when using the role from outside one should never use tasks_from.

Avoidance by using a dispatcher task

Assuming you have a role name foo and you have two actions install and uninstall, you can fully avoid the tasks from by doing something like

## defaults/main.yml
foo_action: install

## tasks/main.yml
- debug: msg="That code runs for both install and uninstall"
- include_tasks: "{{ foo_action }}.yml"

## tasks/install.yml
...

## tasks/uninstall.yml
...

As you can see using a dispatcher allow you to have a list of tasks that run for both actions, something that would be impossible to do if you have multiple entry points.

[drybjed]

Would there be a method to mark a given use of tasks_from as valid and desirable, akin to using warn: False in command and shell modules?

Some roles I maintain are written in a way that would encourage the use of tasks_from, for example to set some facts dynamically via set_fact to be consumed by other roles. Currently to achieve this I'm using a separate env/ subdirectory in a role with symlinked defaults and templates directories when necessary, and calling that "subrole" at the playbook level before the roles that use the dynamically set facts. This was designed before tasks_from was a thing, and I think that now I would gladly convert to that method if it's stable; however I would not want to have a bunch of ansible-lint errors because of that.

Also, even though Ansible currently doesn't have good documentation tools to describe the use of a role, that doesn't meant that this documentation cannot be written elsewhere. Role users can be directed towards the role documentation if any issues arise.

[ssbarnea]

Building roles with multiple entry-points makes sense and recently I heard something that is likely to address the conundrum: the idea is to consider tasks_from a linting issue only if the role does have a default entry point (main.yml). If a role does not have a default entry point, we can assume it was designed to be used with specific tasks.

The whole point of this was to avoid accidents when someone imports a role.

IMHO, if you want a default entry point, you can also use an action variable as router, so your users are supposed to use that one instead of tasks_from.

[bbaassssiiee]

I'm against this proposal. There are many ways to write roles, the presence of tasks_from could just be a sign of another design than the one you're used to.

Desired State Presentation
Skeleton
GitHub Codespace Demo