---
title: The Novoyuuparosk wiki automation architecture
date: 2026-06-11
tags:
  - CICD
  - Automation
wiki:
  publish: false
---

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.