snowspeeder/roast_command_center
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Document Gitea Actions deployment workflow
Test and deploy / test-and-deploy (push) Successful in 1m4s
Details

Browse Source
This commit is contained in:
snowspeeder
2026-07-31 06:30:20 -04:00
parent e51bfd3dca
commit df5c4aef48
1 changed files with 3 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+3 -1
View File
@@ -2,7 +2,9 @@
Run `npm test` before every commit and whenever changing authentication, API authorization, service-worker behavior, or persistence. Add a regression test under `test/` for every new route and for every security/ownership bug. Tests use an in-memory PostgreSQL-compatible database; production migration is run automatically at startup against `DATABASE_URL`.
Every change pushed to the remote must be deployed to the Unraid Docker service immediately afterward. Verify the deployed container is healthy and the production endpoint responds before reporting completion. Production runs from `/mnt/user/dev/roast_command_center` on xNAS. The Gitea Actions runner is the `gitea-act-runner` container (registered as `unraid-roast-deployer`); use it for the eventual push-to-`master` test/deploy workflow. Do not create duplicate runners, and never expose a runner registration token in a command, log, or commit.
Pushes to `master` automatically run `.gitea/workflows/deploy.yml`: it installs dependencies, runs `npm test`, builds/recreates the Unraid Docker project, and verifies both the container and `https://roast.srmr.xyz/`. Watch each run in **Repository → Actions**; do not report a pushed change complete until its Actions run succeeds. Production runs from `/mnt/user/dev/roast_command_center` on xNAS. The self-hosted Gitea runner is the single `gitea-act-runner` container (registered as `unraid-roast-deployer`); its custom image includes Node, Git, Docker Compose, and curl, and it reads the protected production environment file as `/run/roast-production.env`. Do not create duplicate runners, expose a runner registration token in a command/log/commit, or manually redeploy after a successful pipeline.
The workflow copies its checked-out revision to an isolated `/tmp` build directory before testing and deploying because the runner's host-executor workspace is ephemeral. `docker-compose.yml` accepts `APP_PORT` (production defaults to `8090`); the container-startup test uses `18090` so CI can run alongside production without binding its port.
Docker builds run `scripts/stamp-asset-version.mjs`, which replaces `__ASSET_VERSION__` in browser assets and the service-worker cache. Keep those markers intact: each build must produce fresh CSS/JS URLs so Cloudflare cannot serve a mixed stale frontend. The Docker entrypoint copies the read-only `PI_AGENT_CONFIG_DIR` seed mounted at `/run/pi-agent-config` into writable `/home/node/.pi/agent`; Pi locks `auth.json` at runtime, so do not mount that directory directly over the runtime path or prefill will lose configured model credentials.