update ci

README.md

@@ -30,7 +30,12 @@ updating to a new upstream release is a controlled, reviewable step.
 │   ├── apply.sh            # reset submodules → apply patches → copy overlay
 │   ├── build.sh            # build UI → embed → bun compile → dist/
 │   └── smoke.sh            # launch binary & verify it serves + backend is up
-└── .github/workflows/build.yml
+├── .build/prod/           # Docker builder (Gitea `docker-compose` runner)
+│   ├── Dockerfile         #   Node + Bun + native toolchain
+│   ├── compose.yml        #   mounts repo, runs build.sh
+│   ├── build.sh           #   build + smoke → out/
+│   └── release.sh         #   Gitea-API release + upload
+└── .gitea/workflows/build.yml
 ```
 
 ## What the patches change
@@ -93,15 +98,31 @@ ever need attention on upgrade.
 
 - **Single file via Bun `--compile`.** The server pulls in native `.node` addons
   (`node-datachannel`, `registry-js`, `adbkit`, …). These **cannot be cross-compiled**,
-  so CI builds each OS on its own runner (Linux/macOS/Windows matrix). The `smoke.sh`
-  step is the guard: if a native addon won't load from the embedded FS, it fails there.
+  so the binary is built **per host platform**. `scripts/smoke.sh` is the guard: if a
+  native addon won't load from the embedded FS, it fails there.
+- **Linux only, for now.** CI builds inside a Linux Docker container, which produces a
+  trustworthy Linux x64 binary. Windows/macOS binaries are **not** reliably buildable
+  from Linux Docker (foreign-platform native addons can't be produced or smoke-tested
+  there, and macOS needs signing) — they'd need real Windows/macOS runners.
 - The UI is embedded as `ui.tar.gz` and extracted to `$TMPDIR/httptoolkit-ui-<version>`
   on first run.
 - No `HTK_SERVER_TOKEN` is set, so the local UI talks to the backend without a token.
 
-## CI
+## CI (Gitea Actions, Docker)
 
-`.github/workflows/build.yml` builds the matrix on push/PR and publishes a GitHub Release
-on `v*` tags. **If your CI is Gitea/Forgejo Actions**, this same file works under
-`.gitea/workflows/` or `.github/workflows/`. **If it's GitLab**, it needs porting to
-`.gitlab-ci.yml` (same steps: checkout w/ submodules → `scripts/build.sh` → `scripts/smoke.sh`).
+Matches the `docker-compose` runner convention:
+
+- **`.gitea/workflows/build.yml`** — on a `v*` tag (or manual dispatch): checks out with
+  submodules, runs `docker compose run --rm prod` in `.build/prod/`, then creates a Gitea
+  release and uploads the artifacts via the Gitea API (`secrets.PAT_GITEA`).
+- **`.build/prod/`** — the Docker builder:
+  - `Dockerfile` — Node 22 + Bun + native-build toolchain
+  - `compose.yml` — mounts the repo at `/source`, caches npm/bun
+  - `build.sh` — runs `scripts/build.sh` + `scripts/smoke.sh`, drops the binary in `out/`
+  - `release.sh` — Gitea-API release + asset upload
+
+Tag a release:
+
+```bash
+git tag v1.27.1 && git push origin v1.27.1
+```