Update your requirements.yml with this grisly Ansible playbook.
MIT License
Update your requirements.yml with this grisly Ansible playbook.
This is one of the gookiest Ansible playbooks I've ever written.
But it does something I need, and it's a lot faster than doing it manually, and I do it every few months. So it was worth spending two hours automating the process on a Friday night while watching a Blues game.
The playbook does the following:
requirements.yml
file (at requirements_file_path
).requirements.yml
file.If you're really daring and had a few drinks, you can set requirements_file_backup
to false
, and overwrite your artisinally-handcrafted requirements file with whatever this playbook disgorges 🤮.
You might be wondering at this point: "Why doesn't geerlingguy just run ansible-galaxy update -r requirements.yml
?" Well, unfortunately, update
is not a thing, and might never be, for roles on Ansible Galaxy. Collections can be upgraded now, but unfortunately besides defining requirements ranges, you can't 'lock in' a set of specific known-working versions of collections. Until ansible supports something like a lock file, you have to do it manually, or trust your life to this playbook. I know what I'd do.
geerlingguy.*
roles, and a few others which follow semantic versioning standards. Since Galaxy allows practically anything as a version (heck, you could probably throw a 🦑 in there and it would work), the playbook will likely break your requirements in new and interesting ways if you use roles that do strange things with versioning.roles
in them, not with roles
and collections
. If you have any collections
listed in your requirements file, this playbook will act like they don't exist and they will go 💥.
Let's assume you have a requirements file (requirements.yml
) with contents like:
---
roles:
- name: geerlingguy.ansible
version: 1.2.0
- name: geerlingguy.certbot
version: 3.0.0
- name: geerlingguy.docker
version: 2.1.0
Run the playbook like so:
ansible-playbook main.yml -e "requirements_file_path=path/to/a/requirements.yml"
Go get a coffee (☕️) – it's going to take a while because of how horrifically inefficient it is to use Ansible as a programming language like this playbook does.
Cross your fingers (🤞) and hope it works.
Note: It is highly recommended you track your
requirements.yml
file in a git repository. That way if this playbook mangles it horrifically, you cangit restore requirements.yml
and act like nothing happened 🤐.
MIT.
This playbook was brought into its miserable existence by Jeff Geerling, author of Ansible for DevOps and Ansible for Kubernetes.