# 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/`](pipelines/songs/) | `mikkeli/ncmr-songs` | Song lyric pages | v1 live | 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. ``` / .gitea/workflows/.yml <- workflow: clones this repo, runs renderer (deps pre-baked in job image) novoyuuparosk-auto-wiki/ <- this repo .gitea/workflows/.yml <- reusable workflow stubs (kept for reference; not actively called; may be stale) pipelines// <- 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`: ```bash 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@giteaAutomaton` - `WIKI_BOT_PASSWORD` = the value from *Bot identity* above - `FAPAT` = Full-Access PAT under `mikkeli`, used by source-repo workflows to clone this repo at runtime **Variables:** - `WIKI_BASE_URL` = `https://wiki.novoyuuparosk.org` - `WIKI_API_URL` = `https://wiki.novoyuuparosk.org/api.php` - `URL_TO_GITEA` = Gitea instance base URL (e.g. `http://localhost:3005`). Named with `URL_TO_` prefix — Gitea blocks variable names starting with `GITEA_` or `GITHUB_`. ## Branch naming - This repo: `automation/` for pipeline-development branches (e.g., `automation/songs`). - Source repos: each pipeline's README defines the source-side branch convention (e.g., `autowiki/` in `ncmr-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/` 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`: - [x] User-scoped secrets and variables set per *Gitea Actions setup* above - [x] `WIKI_BOT_USER` - [x] `WIKI_BOT_PASSWORD` - [x] `FAPAT` (Full-Access PAT — value not stored in this README; saved directly into the Gitea secret. Regenerate if lost.) - [x] `WIKI_BASE_URL` - [x] `WIKI_API_URL` - [x] `URL_TO_GITEA` With Pi access: - [x] Add `act_runner` service to the existing Gitea docker-compose - [x] 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/`](pipelines/songs/).