Caching roles and collections on local environment to not rely on upstream

Hi. I have sometimes the issue with external dependencies in requirements.yml (e.g. upstream role name change by the creator or roles/collections disappearing). This causes the project update to fail and therefore the playbooks fail as well when we don’t expect it. What would be the best way to cache upstream roles/collections on the local environment? Is something like artifactory possible or a privately hosted galaxy? Or is there something else?

For example, linuhq.chrony role got merged to the linuxhq.linux collection. This is all fine, but this caused AWX project update to fail since it couldn’t download the role anymore. The awx jobs then complained that since the project failed to update, the playbooks would not run at all.

[WARNING]: - linuxhq.chrony was NOT installed successfully: - sorry,\nlinuxhq.chrony was not found on


A Private Hosted Galaxy is possible:

Details on how to install:

Hope it helps.


You can disable dynamic downloads for Roles and Collections under Settings -> Job Settings, https://your_dns_name_or_ip/#/settings/jobs/edit


However this is a global setting, so it affects all Projects / Job Templates within AWX / Automation Controller


Thanks, but I don’t see the purpose in disabling role/collections download. This causes the playbooks to not work at all since they are missing the roles/collections from the requirements.yml which they are dependent on.

On the command line, there is a switch called --ignore-errors, which solves the problem (at least short term). But this is not available on AWX and the awx code does not provide the option for that anyway

1 Like

IMHO using the requirements is an anti-pattern with execution environments. You will get better performance and more consistent results if you just build an execution environment htat has the roles/collections you need. I most always have this disabled.

The --ignore-errors strategy is a bad one because something is obviously not installing, that you just happen to not use so the playbook can still work. If you happen to use a different parameter, module, etc from the requirements the playbook will break and probably not give a great error to help you troubleshoot it because you ignored an earlier error.

1 Like

I have a requirements.yml in every git project. The reason is simply to see all the requirements this particular project has and to provide the project the exact dependencies it needs. I have multiple projects built the same way.
It might happen now for example (as a fear of mine) that a single dependency has different version across different projects (e.g. upgrading a dependency on a per-project basis to not break everything at once). The approach with built in roles/collections in a single EE then won’t work. I then need to have multiple EE images.
Do you have it this way as well or do you simply have a huge EE image that spans across multiple projects?

But you are right that your approach will speed up things considerably. Thank you.

1 Like

My team uses about 15 execution environments that are built weekly. You can see them here: GitHub - cloin/ee-builds: Automate builds of execution environments for use with Ansible Automation Platform 2

It is basically your same strategy, but separated out the requirements to the EE, so each project has an EE. This means you don’t have to install anything “on-demand” ever and it is much faster and less error prone.


I have not considered it this way at all. This seems to me the better solution compared to a selfhosted ansible galaxy and less effort long term for our environment. Thanks for providing the insight.


it is not an either/or proposition, you CAN use the self hosted galaxy to cache for the EEs also


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