cschulz/rd13_media_wiki
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions
rd13_media_wiki/.github/copilot-instructions.md
Conrad Schulz e8bdd13531 ci: migrate from GitHub Actions to Woodpecker CI on Forgejo 
- Add .woodpecker.yml with build+push on main, dry-run on pull_request
- Image target: 192.168.178.6:8083/cschulz/rd13_media_wiki:latest
- Update copilot-instructions.md: GHCR → Forgejo Registry, GH Actions → Woodpecker
- Update README.md: replace GitHub Actions reference with Woodpecker CI
2026-05-30 11:04:42 +00:00

3.2 KiB
Raw Blame History

GitHub Copilot – Project Instructions

Project

MediaWiki deployment for rd13 – a self-hosted wiki running in Docker, served via a reverse proxy, with a MariaDB backend.

Stack

  • Language: PHP (MediaWiki core + extensions), YAML, Dockerfile
  • Framework: MediaWiki
  • Database: MariaDB
  • Infrastructure: Docker Compose, Forgejo (self-hosted Git), Woodpecker CI, Forgejo Container Registry, Linux Server (remote via VS Code Server)

Architecture

  • Pattern: Containerised deployment (App + DB as separate services)
  • Key constraints: No application code changes – configuration and infrastructure only
  • Image published to: 192.168.178.6:8083/cschulz/rd13_media_wiki:latest (Forgejo Container Registry)
  • Extensions live in: wikidata/extensions/
  • Wiki config: wikidata/LocalSettings.php
  • Upload config: wikidata/uploads.ini

Conventions

  • Branch naming: feat/<ticket>-description, fix/<ticket>-description
  • Commit format: Conventional Commits (feat|fix|chore|docs|refactor|ci)
  • Secrets: never in docker-compose.yml or LocalSettings.php – use .env files or Docker secrets
  • CI/CD: Woodpecker CI pipeline defined in .woodpecker.yml at repo root
  • Images: always pin with a specific tag, avoid :latest in production compose files

Engineering Process

Before starting any task

  1. Clarify requirements – user story + acceptance criteria vorhanden?
  2. Impact analysis – welche bestehenden Komponenten sind betroffen?
  3. Architecture check – passt die geplante Lösung zur bestehenden Architektur?
  4. Test strategy – wie wird das Feature getestet?

Definition of Ready (DoR)

A task can only be started when:

  • Acceptance criteria are clear and unambiguous
  • Non-functional requirements defined (performance, security, scalability)
  • Architectural approach agreed upon
  • No unresolved external blockers

Definition of Done (DoD)

A task is only done when ALL of the following are true:

  • Change implements the acceptance criteria
  • No secrets or credentials in code or config
  • OWASP Top 10 reviewed
  • Relevant documentation updated (README, if applicable)
  • Commit message follows Conventional Commits
  • Docker image builds successfully (docker buildx build --platform linux/amd64 .)
  • No dead config, no TODOs left behind (or tracked as issues)

Testing Strategy

  • No unit/integration tests (deployment-only repo)
  • Validation: docker compose config for compose syntax
  • Build test: Woodpecker CI pipeline runs docker buildx build (dry-run) on PRs, build+push on merge to main

Security

  • No secrets in code or config files – use environment variables / .env
  • MediaWiki $wgSecretKey and DB passwords must come from env or secrets
  • Validate all extension configurations before enabling
  • Principle of least privilege for all container permissions
  • Dependency vulnerabilities: check before adding new extensions or base image versions

Documentation Standards

  • Code comments: explain WHY, not WHAT
  • Architecture decisions: write ADR in docs/adr/ (template: docs/adr/000-template.md)

Non-Functional Requirements

  • Availability: 99% (self-hosted, single node)
  • Data retention: persistent volumes for wikidata/ and mdbdata/
  • Response time: < 2s for wiki page loads