Own "role" cant find role

Get Help
,
1

Hello again!
I want to have a Playbook running in the background which checks for github releases.
I used to learn the recommended folder structure, but the playbook cant find the roles.
I Run the check_releases.yaml.
Structure:
ansible-project/
├── inventory
│ └── hosts
├── playbooks
│ └── check_releases.yaml
├── roles
│ ├── github_release_check
│ │ ├── tasks
│ │ │ ├── main.yaml
│ │ │ └── load_previous_releases.yaml
│ ├── rocketchat_notify
│ │ ├── tasks
│ │ │ └── main.yaml
├── group_vars
│ └── all.yaml

And this is my playbook:

---
- name: Check for new GitHub releases and notify via Rocket.Chat
  hosts: localhost
  gather_facts: false
  roles:
    - github_release_check
    - rocketchat_notify

grafik
grafik1009×444 29.1 KB

The Log:

ERROR! the role 'github_release_check' was not found in /runner/project/functions/check_gitgub_releases/playbooks/roles:/runner/requirements_roles:/runner/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles:/runner/project/functions/check_gitgub_releases/playbooks

The error appears to be in '/runner/project/functions/check_gitgub_releases/playbooks/check_releases.yaml': line 6, column 7, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

  roles:
    - github_release_check
      ^ here

The githubreleasecheck main:

---
- name: Check GitHub releases
  vars:
    releases_file: /tmp/github_releases.json
  block:
    - name: Fetch latest releases from GitHub
      uri:
        url: "https://api.github.com/repos/{{ item.owner }}/{{ item.name }}/releases/latest"
        return_content: yes
        headers:
          Accept: "application/vnd.github.v3+json"
      register: github_response
      loop: "{{ github_repos }}"
      changed_when: false

    - name: Parse GitHub release data
      set_fact:
        new_releases: "{{ github_response.results | selectattr('status', 'eq', 200) | map(attribute='json') | list }}"
      
    - name: Load previous releases data
      include_tasks: load_previous_releases.yml
      when: releases_file is file

    - name: Save current releases data
      copy:
        content: "{{ new_releases | to_nice_json }}"
        dest: "{{ releases_file }}"
      changed_when: false

Thank you very much again!!

2

Hi,

I see that you are executing on localhost. It could be that you are executing within a runtime environment that does not include your role.

In that case you might want to create a custom runtime environment that contains the roles

1 Like
3

Or what i found just a minute ago - drop all in the Playbooks folder:
github_release_check/
├── inventory
│ └── hosts
├── playbooks
│ ├── check_releases.yaml
│ ├── group_vars
│ │ └── all.yaml
│ ├── roles
│ │ ├── github_release_check
│ │ │ ├── tasks
│ │ │ │ ├── main.yaml
│ │ │ │ └── load_previous_releases.yaml
│ │ ├── rocketchat_notify
│ │ │ ├── tasks
│ │ │ │ └── main.yaml

4

This is exactly the same problem another user had (here). It makes me wonder if there’s a document out there, or some tool, or some “intro to Ansible” blog post, that’s recommending putting playbooks inside a playbook directory.

@gothsome, do you remember where did you get the notion to create a separate playbook directory?

1 Like
5

Hello!
Yes - i fouund it in this Reddit Post.
But they dont explan why or sources and i cant even find a official guide stating it like this here.
I dont knoww if its a bug i should report at the git?
It chould be easy to set roles yourself with this folder sturucture without going the long way in integating it into a new enviroment.

6

I see. That whole thread is about the same problem. It was “resolved” about 4 months ago, but not well.

Sample Ansible setup — Ansible Community Documentation contains the following:

Note

By default, Ansible assumes your playbooks are stored in one directory with roles stored in a sub-directory called roles/. With more tasks to automate, you can consider moving your playbooks into a sub-directory called playbooks/. If you do this, you must configure the path to your roles/ directory using the roles_path setting in the ansible.cfg file.

(Or override that ansible.cfg setting with an environment variable.)

It can hardly be more plain than that. [sigh]

2 Likes
7

i still answered him maybe he can continue.

8

I searched like a madman for this page - i know i aleready read it, but i couldnt find it in the end again… Thank you!

… i looked the example upd and its for me not 100% enough like in the first example there ist no place for the main playbook mentioned.

9

I found here maybe an explanation why this movin in the Playbooks Folder makes the playbook run again.

in the first exaple of the odfficial guide there is the main playbook missing and the secon one there ist the main playbook in the root and from then there are the roles and variables so if i move eberything like i did in my folders and ignore everything before the playbok folder i have the secon d method which is useed in the other guide.
And with the use of the chatbots which get you something like this, which looks in the first look like the first example of the official docu.
The first onoe i got from gpt was:

projektname/
│
├── inventories/
│   ├── production/
│   │   ├── hosts               
│   │   └── group_vars/
│   │       └── group1.yml      
│   ├── staging/
│       ├── hosts               
│       └── group_vars/
│           └── group1.yml      
│
├── roles/
│   ├── rolle1/
│   │   ├── defaults/
│   │   ├── handlers/
│   │   ├── meta/
│   │   ├── tasks/
│   │   ├── templates/
│   │   └── vars/
│   └── rolle2/
│       ├── defaults/
│       ├── handlers/
│       ├── meta/
│       ├── tasks/
│       ├── templates/
│       └── vars/
│
├── playbooks/
│   ├── playbook1.yml           
│   └── playbook2.yml           
│
├── files/                      
│
└── ansible.cfg

But should be like:

awx_project/
├── inventory/
│   ├── production
│   ├── staging
│   └── testing
├── group_vars/
│   ├── group1.yml
│   └── group2.yml
├── host_vars/
│   ├── host1.yml
│   └── host2.yml
├── library/
├── module_utils/
├── filter_plugins/
├── master.yml
├── webservers.yml
├── dbservers.yml
└── roles/
    ├── example_role/
    │   ├── tasks/
    │   │   └── main.yml
    │   ├── handlers/
    │   │   └── main.yml
    │   ├── templates/
    │   │   └── ntp.conf.j2
    │   ├── files/
    │   │   ├── bar.txt
    │   │   └── foo.sh
    │   ├── vars/
    │   │   └── main.yml
    │   ├── defaults/
    │   │   └── main.yml
    │   ├── meta/
    │   │   └── main.yml
    │   ├── library/
    │   ├── module_utils/
    │   └── lookup_plugins/
    └── another_role/
        ├── tasks/
        ├── handlers/
        ├── templates/
        ├── files/
        ├── vars/
        ├── defaults/
        ├── meta/
        ├── library/
        ├── module_utils/
        └── lookup_plugins/
10

I have one project (and only one! out of a couple of dozen) where all my playbooks names are prefixed with “apb_” which means “Ansible PlayBook”. That keeps them together when listing the top level directory. Why I do that in only one project I can’t explain, but it somehow seems natural at this point. Go figure.

11

I have always done this, but can not remember where I picked this up. It might have been a practice I picked up when switching from puppet to ansible. And I might have been spreading this around to others as well. I have not had any issues as I just configure the roles directory in my ansible.cfg file.

The main reason for having a playbooks folder is to clean up the workspace. Some of my projects have a few dozen playbooks so leaving them all in the root folder makes it quite messy.

I would appreciate it if the search path for ansible were changed to also include the current working directory or detecting if the playbook is run within a playbooks directory and also search the parent directory. This is not only a problem for roles but also files and templates.

12

Well, that’s another whole issue by itself. There isn’t “a” search path for Ansible. Behold:

$ ansible-config dump | grep -E -o '^\w*PATH?\b'
ANSIBLE_CONNECTION_PATH
ANSIBLE_COW_PATH
BECOME_PLUGIN_PATH
COLLECTIONS_SCAN_SYS_PATH
DEFAULT_ACTION_PLUGIN_PATH
DEFAULT_CACHE_PLUGIN_PATH
DEFAULT_CALLBACK_PLUGIN_PATH
DEFAULT_CLICONF_PLUGIN_PATH
DEFAULT_CONNECTION_PLUGIN_PATH
DEFAULT_FACT_PATH
DEFAULT_FILTER_PLUGIN_PATH
DEFAULT_HTTPAPI_PLUGIN_PATH
DEFAULT_INVENTORY_PLUGIN_PATH
DEFAULT_LOG_PATH
DEFAULT_LOOKUP_PLUGIN_PATH
DEFAULT_MODULE_PATH
DEFAULT_MODULE_UTILS_PATH
DEFAULT_NETCONF_PLUGIN_PATH
DEFAULT_ROLES_PATH
DEFAULT_STRATEGY_PLUGIN_PATH
DEFAULT_TERMINAL_PLUGIN_PATH
DEFAULT_TEST_PLUGIN_PATH
DEFAULT_VARS_PLUGIN_PATH
DOC_FRAGMENT_PLUGIN_PATH
GALAXY_TOKEN_PATH
RETRY_FILES_SAVE_PATH
1 Like
13

I had one more thought on this that maybe will benefit somebody. And since I’m an old fart, you get a campfire story out of it.

When we first started playing with Ansible, we made a point of studying all the things you could tweak through ansible.cfg. The documents at that time were nowhere near as good as they are now, so that meant a lot of experimentation. We had one-off variants of one-off variants spreading all over the place. And we learned a lot.

Q. What’s the most important thing we learned about tweaking ansible.cfg?
A. “To not to.” — 'Mater, the movie ‘Cars’, 2006

Where we landed has one ansible.cfg file on any host where we develop or test/pre-test ansible code, and that’s /etc/ansible/ansible.cfg. The only things in it are there specifically to make it behave as much like our AWX instance as possible. The existence of any other ansible.cfg file on a host is considered an error.

That’s not to say we don’t override defaults: ANSIBLE_VAULT_IDENTITY, ANSIBLE_VAULT_IDENTITY_LIST, and ANSIBLE_INVENTORY for example. But we don’t do it through ansible.cfg because the first one found wins. Any overriding of defaults we need to do, we do through environment variables. That way /etc/ansible/ansible.cfg still gets loaded, and the environment variables have the final say on any deviation from the default settings.

The corollary is, if you’re doing something elective that’s going to require overriding a default, you’re probably making a mistake. For example, if you’re going to move your playbooks from the top level of your project to a bespoke ./playbook/ directory, that’s going to require a tweak to your DEFAULT_ROLES_PATH. And that tweak will need to be carried over for as long as you – or anybody else – uses that project. That’s a clue that you’re making a mistake. It’s bad enough to put that burden on yourself, but you’d be putting it on your co-workers and successors, too. Just, don’t! Make your stuff work with the defaults if reasonably possible.

Any variation from defaults is easily determined via

$ ansible-config dump --only-changed

That also shows you where your snowflakes are coming from. Review it regularly and try to keep it to a minimum. Embrace and enjoy the ensuing sanity.

14

yeah this is the way i like to keep things always.
because of this i used the ee above anything.

What i leared that setting up an ee looked comlicated to handle, but its just an Container with custom settings which you upload at docker.hub and connect in AWX with the Execution enviroment.

Just like installing anible operator updates:change the version in the configs and pull! :laughing:

1 Like
15

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