Continuous Integration

Continuous Integration

Every claim this repository makes about working is a claim about a machine that is not the author's. CI is the only thing that can settle it, so the workflow is written to prove specific statements rather than to go green.

What each job proves

Job	The claim it settles
install + boot × 6	a clean checkout installs, migrates, imports, serves, and reports its health — on Ubuntu and Windows, on Python 3.10, 3.11 and 3.12
test suite × 2	601 tests pass on both operating systems
no personal data	nothing operator-private has crept back into a repository assembled from a private instance
docker image builds and serves	the compose route — the one most first-time users take — actually works

Ten checks, no allowed failures.

Why the boot job has eleven small steps

A single compound script that fails tells you the job failed. It does not tell you where. Each step is deliberately small — Environment, Install dependencies, Installed packages, Seed config from templates, Migrate the database, Import the application, Start the server, Probe health — so a failure names itself. The server log is printed with if: always(), because the run where you most need the log is the run that failed.

What the runner is, and what it is not

A GitHub runner has no model runtime. That is not a broken environment — it is exactly what a first-time user's machine looks like before they start Ollama, and the House supports that state (they may intend to use a cloud connection instead).

So the health probe fails on RED checks only, not on ok:false:

• RED — the House itself is faulty. A missing file, a module that will not import, a corrupt database, a broken audit chain.
• YELLOW — running, with something optional absent. On a runner: no model runtime.

Reporting an absent local runtime as RED is a mistake this project made and fixed; it failed all six boot jobs, and it would have told every new user that a correct install was broken. See Troubleshooting.

The privacy job

This repository was assembled from a private working instance, so "no personal data" is not a property it has — it is a property it has to keep re-earning on every push.

tools/privacy_scan.py enforces it, and two of its design decisions were learned the hard way:

1. It scans git-tracked files only. Walking the working tree flagged git-ignored generated artifacts — noise that hides real findings.
2. It rejects a class, not a list. The first version enumerated known-bad strings and passed while real leaks sat in the tree, because they were paths nobody had thought to enumerate.

It is a committed script rather than a script inlined in the workflow, so that anyone can run the same gate locally:

python tools/privacy_scan.py

An inline version cannot be run locally, and a gate you cannot reproduce is a gate you end up trusting on faith.

Running the checks yourself

cd backend && python migrate.py up && python -m pytest -q   # the test suite
python tools/privacy_scan.py                                # the privacy gate
docker build -t skynetclaw:local .                          # the image

---

A green badge is a claim. These jobs are what makes it true.