2.4 KiB
title, date, tags, wiki
| title | date | tags | wiki | ||||
|---|---|---|---|---|---|---|---|
| The Novoyuuparosk wiki automation architecture | 2026-06-11 |
|
|
Roughly how this wiki is automated, and something the codes as infrastructure won't tell you directly.
The motivation
Apparently, automating a wiki is not exactly the most rewarding thing to do. But I already have a Gitea instance running to put my more private stuff in, and I have a rather powerful Pi doing less than it could.
The gain is actually massive. Without this automated pipeline I need an Internet connection, I need to open up my browser, get to my wiki and write. Now I only need to open VSCode to write, and git commit, and push, and make a PR or silently merge to master to activate the runner. Definitely a lot easier.
The biggest real gain I see is automated category tags and unified typesetting, which can be done with mediawiki templates, at a fraction of the cost of setting up this whole 'CI/CD'. But overengineering is a passion, as long as it's fun.
The architecture
Gitea
Gitea is simply run from Docker as a container. It requires postgre anyway and I need to access Gitea away from home so a docker compose profile with three components (initially) is very natural: gitea, postgre, and rathole. Rathole is for the Internet exposure and I believe frpc is OK too. I have some other services exposed via frpc.
A slight deviation from what I just stated is that postgre is actually not configured in the Gitea configuration. I have a postgre for other services already and I just pointed the Gitea container to join that network.
Runner
I like overengineering, but implementing industrial grade ephemeral runner machines or containers is too much and stops being fun. So the runner is just a persistent container registered to Gitea once, on a user scope. I didn't even set up a organisation, the user IS the organisation.
This single runner would poll Gitea for all of the pipelines (or the other way round, if I got it wrong). When there is a job it would do it.
Job container(s)
The main job, going over markdowns, convert to wikitext using pandoc, and publishing to mediawiki via API, is done in a custom image which has git, pandoc (apparently), Python, and some other dependencies.
There exist slightly diffferent flavoured pipelines for different kinds of articles but that differentiation is in the Python scripts, not in the image.