This solution relies purely on ansible and doesn't require any additional modules. All you need is to specifiy your roles and include the tasks from /simple/tasks.yml
.
As this uses the git-module, most of the configuration here is diretly used on this module.
Here is an example-configuration:
---
role_deps:
accept_hostkey: yes
roles_dir: "roles/"
fail_when_changed: false
roles:
- name: postgres
repo: "https://github.com/geerlingguy/ansible-role-postgresql.git"
version: "3.2.0"
Explanation:
accept_hostkeys
: skips the hostkey-check if set toyes
. Can be set globally and overridden on each role (default:no
)roles_dir
: where to store the roles (default:roles/
)
If you change that, you need to make sure that the directory is in the search-path yourself!default_role_loc
: if set, you can omitrepo
in the role, the repo will then be constructed asdefault_role_loc + name + '.git'
fail_when_changed
: Fail after pulling all roles if at least one of them changed. See Limitations for more information. (default:false
)allow_local_modification
: if set totrue
, the process will not fail if a repository can't be updated because of local changes. You might want to set this totrue
in dev andfalse
in prod (default:false
)roles
: a list of roles to manage (required)roles[*].name
: the name of the directory inroles
where the role is stored (required)roles[*].repo
: the repository where the role is managed (required ifdefault_role_loc
is not defined)roles[*].version
: version (tag/branch/hash) to check out (default:master
)
The role will ensure the roles_dir
directory exists and then ensure the specified versions of all specified roles are in there. It will clone missing roles and check out the specified versions if necessary.
- Nested dependencies (e.g. such specified in a role in
meta/main.yml
) are not taken into account. If those exist, you need to list them inrole_deps.roles
. - No validation of roles. You can specify any repository. If it doesn't contain a valid role, this will not fail.
- Only works with
include_role
, not withimport_role
if it is in the same playbook. This is due toimport_role
processing the role before the version is updated. So if you useimport_role
, your role will be updated but the old version of the role will run. - Doesn't work with the
roles
-directive of plays, as the role needs to be present when the playbook starts running.
To work around the last two items, you can set role_deps.fail_when_changed
to true
to make sure you use the lates version with import_role
even if it changed. The role still needs to be present before running, though.