act starts job containers with entrypoint /bin/sleep, which kaniko's scratch-based image lacks (busybox lives under /busybox). kaniko-act adds the single missing symlink; bootstrap build is manual, documented in the Dockerfile. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
novoyuuparosk-auto-wiki
CI/CD pipelines that auto-apply commits to https://wiki.novoyuuparosk.org from upstream content repos.
Pipelines
| Path | Source repo | Purpose | Status |
|---|---|---|---|
pipelines/songs/ |
mikkeli/ncmr-songs |
Song lyric pages | v1 live |
pipelines/ses/ |
mikkeli/ses-light-novel |
SES light novel pages | v1 in development |
pipelines/tech/ |
mikkeli/tech-blogs |
Tech blog posts | v1 ready (source repo not yet initialised) |
Per-pipeline READMEs cover everything specific to that pipeline (source schema, renderer, runtime, decisions). This root README covers only what's cross-cutting.
Architecture
Hybrid layout. The Gitea Actions trigger must live in the source repo (Gitea only fires workflows from .gitea/workflows/ of the pushed-to repo); the rendering logic lives here. The source-repo workflow is self-contained but clones this repo at runtime to get the renderer.
<source-repo>/
.gitea/workflows/<name>.yml <- workflow: clones this repo, runs renderer (deps pre-baked in job image)
novoyuuparosk-auto-wiki/ <- this repo
.gitea/workflows/<pipeline>.yml <- reusable workflow stubs (kept for reference; not actively called; may be stale)
pipelines/<pipeline>/ <- per-pipeline code, schema, templates
lib/ <- shared modules (MediaWiki client, etc.)
Note: workflow_call across private repos was abandoned — the auto-generated run token is scoped to the triggering repo only and cannot clone a private callee. The source-repo workflow clones this repo directly using FAPAT.
Wiki
- Base URL: https://wiki.novoyuuparosk.org
- MediaWiki API: https://wiki.novoyuuparosk.org/api.php (confirmed)
Bot identity
MediaWiki BotPassword issued for user Dubrowski, bot name giteaAutomaton. Login form: Dubrowski@giteaAutomaton.
Credentials are stored in the Gitea user-scope secret vault under mikkeli (WIKI_BOT_USER, WIKI_BOT_PASSWORD). Not stored in this repo.
Runner infrastructure
One act_runner instance serves all pipelines. Runs on a Pi 5 (Raspberry Pi OS Bookworm, aarch64) inside the same docker-compose stack that hosts the Gitea instance. Job execution is via the host Docker socket — runner is a container, jobs spawn as sibling containers.
act_runner build: linux-arm64, from the gitea/act_runner Docker image.
Container network mode: host — required so job containers can reach localhost:3005 (Gitea) and resolve mDNS hostnames.
Job container image
All pipelines share a single pre-built Docker image: novoyuuparosk-wiki-runner:latest. The Dockerfile is at the repo root. It bakes in system deps (git, pandoc, ca-certificates) and all pipeline Python packages so job containers start instantly with no install steps.
The image is built manually on the Pi and stored in the local Docker daemon (pull_image: false in act_runner config). Rebuild after any change to the Dockerfile or a pipeline requirements.txt:
docker build -t novoyuuparosk-wiki-runner:latest \
/home/mikkeli/dev/novoyuuparosk-auto-wiki
Gitea Actions setup (cross-cutting)
Secrets and variables are scoped to user mikkeli (no orgs on this instance), inherited by all repos under that account.
Secrets:
WIKI_BOT_USER=Dubrowski@giteaAutomatonWIKI_BOT_PASSWORD= the value from Bot identity aboveFAPAT= Full-Access PAT undermikkeli, used by source-repo workflows to clone this repo at runtime
Variables:
WIKI_BASE_URL=https://wiki.novoyuuparosk.orgWIKI_API_URL=https://wiki.novoyuuparosk.org/api.phpURL_TO_GITEA= Gitea instance base URL (e.g.http://localhost:3005). Named withURL_TO_prefix — Gitea blocks variable names starting withGITEA_orGITHUB_.
Branch naming
- This repo:
automation/<pipeline-name>for pipeline-development branches (e.g.,automation/songs). - Source repos: each pipeline's README defines the source-side branch convention (e.g.,
autowiki/<song-slug>inncmr-songs).
Decisions log (cross-cutting)
| Decision | Value | Date |
|---|---|---|
| Architecture | Hybrid: source-repo workflow clones this repo at runtime for the renderer | 2026-06-09 |
| Workflow pattern | Self-contained (not workflow_call) — cross-repo workflow_call blocked by token scoping on private repos |
2026-06-09 |
| Runner execution | Docker, added as a service to the existing Gitea docker-compose | 2026-06-09 |
| Runner network mode | host — job containers need to reach Gitea on localhost |
2026-06-09 |
| Secret/runner scope | User-level on mikkeli (no orgs on this instance) |
2026-06-09 |
| MediaWiki API path | api.php (classic action API) |
2026-06-09 |
| Branch naming (this repo) | automation/<pipeline> for pipeline-development branches |
2026-06-09 |
| Variable naming | URL_TO_GITEA not GITEA_URL — Gitea blocks GITEA_/GITHUB_ prefixes |
2026-06-09 |
Per-pipeline decisions live in each pipeline's README.
Setup checklist (cross-cutting)
Via the Gitea web UI logged in as mikkeli:
- User-scoped secrets and variables set per Gitea Actions setup above
WIKI_BOT_USERWIKI_BOT_PASSWORDFAPAT(Full-Access PAT — value not stored in this README; saved directly into the Gitea secret. Regenerate if lost.)WIKI_BASE_URLWIKI_API_URLURL_TO_GITEA
With Pi access:
- Add
act_runnerservice to the existing Gitea docker-compose - Generate a runner registration token at
/-/admin/actions/runners, bake into the compose env,docker compose up -d act_runner, confirm "online" in the Gitea UI
Per-pipeline setup lives in each pipeline's README. Start with pipelines/songs/.