-
Notifications
You must be signed in to change notification settings - Fork 1
Description
Issue to track planning, questions, and answers related to moving the wiki.js installation and configuration to a dedicated role.
I am considering two pathways:
- moving the information in the existing playbook to a role
- selecting an existing wiki.js role and mapping the config onto it
1. creating a new custom role
This ought to be quite easy. In this process, i would like to lift variables related to upgrading so that's easier. Right now the version selection is managed in the install.sh script. Would be nice to manage this with a single variable for future upgrades.
2. Selecting existing role
https://github.com/pmoscode/wikijs looks the most active and featureful.
There's 3 roles in ansible galaxy: one is empty, this one, and the role this one is forked from.
The pmoscode role (and it's parent) has the standard role layout and good separation of defaults, tasks, templates, etc. Looks updated to include deployment to an ubuntu host.
I am going to investigate further what it will take to use this role mapped onto the existing installation.
At first glance:
- variables are namespaced correctly and can be lifted to host_vars
- Tasks almost entirely refer to variables
- The version is selected via a variable
- The vars are not well documented even if obvious from the name
In my opinion that's a well written role which can serve at least as a basis for a custom role.
An open question is how best to include the role if deemed appropriate:
- a custom role is clearly just written into the
rolesdirectory - an existing role can be forked and included
- ... could be a git submodule
- ... could be managed via ansible-galaxy with a requirements.yml
tbqff: probably just want to base a custom role off pmoscode's or it's parent.
feedback is appreciated, but I will continue gathering information and will write up PR before it's required