How to use a different entry point in the `roles` part

Get Help
1

In some of my roles I would like to use different entry points (not the usual main.yaml under tasks, but other.yaml).

The relatively new Role argument validation (see the start of the specs) has primary support for entry points.

For include_role / import_role this is well supported using the tasks_from keyword.

But for the “old” roles: part in a play, it doesn’t seem to be supported. At least, according to this stackoverflow post:

Why is it not supported for the roles: part?

  • Am I just missing the proper documentation on how to call it with an entry point? Then maybe someone please go ahead and post a new answer on that stackoverflow posting. Please.
  • Is this considered so advanced, that you’re anyway expected to use include_role / import_role?
  • Is the roles: part heading towards a deprecation?

Just wondering…

2

I don’t know if there is official documentation concerning this, but when I started using Ansible several years ago, multiple people on IRC told me not to use the roles: , as it was the “old” way to do it and would be deprecated…instead to use include_role / import_role, which were far more advanced and the future standard.

So I have never used roles: myself, and don’t believe there is any benefit to it…

2 Likes
3

I have found this old thread that also suggests this: "import_role" vs "roles"

IMHO it would really be helpful, if there was some more information on possible deprecation plans.

Benefit… depends on the view. If you have a few simple roles, then

roles:
- role1
- role2
- role3

is quite concise. Doing the same in the new syntax is something like this:

tasks:
- ansible.builtin.import_role:
    name: role1
- ansible.builtin.import_role:
    name: role2

which feels quite verbose.

Yes, you could use include_role and loop:. But include_role has different semantics than import_role (which is closer to roles:).

4

Don’t believe random people on the internet (including me). While i WISH this were true, roles: is not deprecated and is not going anywhere, but it is also not going to get new features as the way it works is very different from what we can do with include_role/import_role.

2 Likes
5

Ehh, I guess it’s a matter of taste. I would rather have it be “verbose” myself - easier to remember things months/years later when you/others are reviewing code :slight_smile:

Good note, thanks. I find include/import role to work great for what I need.

1 Like
6

Is there any documentation on this?

For example the Using roles at the play level docs do not mention that using include/import-role is rather recommended except for the “The classic (original) way to use roles” at the beginning.

7

There is no official recommendation of one over the other, the point is that they work differently and are not expected to have the same features, if they were all the same, only one would exist.

My personal recommendation is to avoid roles/pre_tasks/post_tasks as I (me, myself and no one else) feel that they add unneeded complexity to plays.

There is only one case I can find for pre_tasks and there is still a better workaround, executing something before gathering. But you can also:

gather_facts: false
tasks:
 - dostuff:

- gather_facts: 
  when:  ansible_facts.get('module_setup', False)
1 Like
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.