Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move wiki.js to dedicated role #14

Open
marcidy opened this issue Jan 25, 2023 · 4 comments
Open

Move wiki.js to dedicated role #14

marcidy opened this issue Jan 25, 2023 · 4 comments

Comments

@marcidy
Copy link
Contributor

marcidy commented Jan 25, 2023

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:

  1. moving the information in the existing playbook to a role
  2. 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:

  1. a custom role is clearly just written into the roles directory
  2. an existing role can be forked and included
  3. ... could be a git submodule
  4. ... 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

@marcidy
Copy link
Contributor Author

marcidy commented Feb 14, 2023

Diffing the pmoscode role against what's installed, there is not much overlap. We use a different storage and auth scheme.

@marcidy
Copy link
Contributor Author

marcidy commented Feb 15, 2023

@marcidy
Copy link
Contributor Author

marcidy commented Feb 22, 2023

The migration guide requires following the installation instructions as the upgrade cannot be done in place.

https://docs.requarks.io/install/requirements

mentions requiring PostgreSQL. This is getting to be a headache.

@marcidy
Copy link
Contributor Author

marcidy commented Mar 6, 2023

and the upgrade also requires an update to node {12,14,16}. which will require some extra work to get a role for that dep.

Note that I do see the git backup stuff still available in wikijs, but i need to complete the upgrade to make sure it actually works. I'll include instructions and maybe include some vagrant config to help test infra changes in general.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant