Files
FabledSteward/ci-requirements.md
T
bvandeusen d925709c77
CI / lint (push) Failing after 2s
CI / unit (push) Successful in 7s
CI / integration (push) Successful in 2m8s
ci: add Forgejo CI (lint + unit + Postgres integration) + ci-requirements.md
Single-repo CI now that plugins are bundled in-tree. Three lanes on push to
dev/main, modeled on FabledCurator's canonical ci.yml (minus frontend/Redis):
- lint: ruff check steward/ plugins/ tests/ (no dep install)
- unit: pytest -m 'not integration' — whole current suite (testing=True mocks DB)
- integration: postgres:16-alpine service via socket-discovered bridge IP; a
  boot-and-migrate test creates the real app, running core + all bundled-plugin
  migrations, then round-trips the DB — guards the folded-in migration graph.

Registers the 'integration' pytest marker; adds tests/integration/test_boot.py.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-01 08:37:32 -04:00

2.2 KiB

CI Requirements — Steward

Spec: https://git.fabledsword.com/bvandeusen/CI-runner/src/branch/main/docs/process.md

Runtime image

git.fabledsword.com/bvandeusen/ci-python:3.14

Image deps used

  • python 3.14
  • ruff (analyzer for steward/, plugins/, tests/)
  • docker CLI (integration lane: bridge-IP discovery of the Postgres service container)

Per-job tool installs

  • uv pip install --system -e '.[dev]' (pip fallback) — in unit and integration jobs. Steward declares its deps in pyproject.toml; the [dev] extra adds pytest + pytest-asyncio. No requirements.txt is tracked.

Lanes

  • lintruff check steward/ plugins/ tests/, no dep install.
  • unitpytest -m "not integration". The whole current suite runs here: it builds the app with testing=True, which mocks db_sessionmaker, so no DB is touched. First-party plugins are bundled in-tree under plugins/, so plugin unit tests import them directly — no cross-repo checkout.
  • integrationpytest tests/integration -m integration against a postgres:16-alpine service. The single test boots the real app (create_app(testing=False)), which runs core + every bundled plugin's migrations, then round-trips the DB. This is the guard that the folded-in plugin migration graph resolves.

Notes

  • Steward has no frontend and no Redis/Celery (no external workers), so there is no frontend-build lane and the only service container is Postgres.
  • Integration uses Forgejo Actions services: + a socket-discovered bridge IP because act_runner (swarm-runner v0.6+) puts services on the default bridge with no embedded DNS. FabledCurator's ci.yml is the canonical example of the pattern; Steward's is the same shape minus Redis and minus sharding.
  • The job name integration has no underscore — act_runner strips underscores from job names when building service-container labels, so the docker ps name filter uses the bare job name.
  • Migrations run via the app itself (create_apprun_core_migrations, async through asyncpg), so the integration lane needs no separate alembic upgrade step and no psycopg/sync driver.