techy/Media-Server-Setup
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Bot releases install themselves: signed bundle upload to dumpd, no Docker socket in CI

Browse Source 
dumpd gains POST /deploy-bot on the bridge-only auth port: HMAC-SHA256 over the body with BOT_DEPLOY_SECRET,
a 300 MB cap, one install at a time, and the installer's output returned in the response so the CI job shows
it. BOT_DEPLOY_AUTO=0 makes the server refuse. configure.py generates the secret, writes both settings into
/etc/vanguard/deploy.env, installs deployBotBundle.sh as /usr/local/bin/vanguard-deploy-bot and creates
/srv/bot/app; --show prints what to paste into Gitea.

Chose this over mounting the Docker socket into job containers, which would give every CI job root on the
host. Also moved threading/subprocess to dumpd's module imports, which the new module-level lock needs.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Brandyn / Techy
2026-11-02 21:32:34 -06:00
parent 22dcf893d5
commit b05f129bed
8 changed files with 111 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
bot/AGENT.md
View File

@@ -43,9 +43,14 @@ Your CI (`.gitea/workflows/ci.yml`, job `bundle`) runs after the tests and produ
`vendor/` is `pip install --only-binary=:all: --target vendor -r requirements.txt`, built on `python:3.12`
so the wheels match the runtime image's ABI. `BUILD.json` records the version, commit, build time, the
package list and a sha256 of every file. The admin installs it with `./deployBotBundle.sh <bundle.tar.gz>`,
which checks the bundle against `BUILD.json`, keeps the previous release for `--rollback`, and restarts the
container. Rules that follow from this:
package list and a sha256 of every file.
**A push to `main` deploys itself.** The workflow's last job posts the bundle to the server's deploy service,
signed with the repository secret `BOT_DEPLOY_SECRET`; the server verifies the signature and every checksum,
keeps the previous release for rollback, and restarts the container. The install log comes back in your CI
job, so a failed deploy fails the run. Branches and pull requests test and build, and deploy nothing.
Rules that follow from this:
- Keep `requirements.txt` resolvable with **prebuilt wheels only**; a dependency that must compile will fail
the build. Ask the admin if you truly need one.
@@ -123,9 +128,9 @@ message content; Message Content is a privileged intent, enable it only if you n
## 6. Working with the admin
- **Source**: push to the community Gitea. CI runs your tests on the `python` runner label, then builds the
release bundle (§1a); the admin installs it with `deployBotBundle.sh`. Pushes to `main` can install it
automatically once the repository variable `BOT_AUTO_DEPLOY` is set to `1`; it is unset by default.
- **Source**: push to the community Gitea. CI runs your tests on the `python` runner label, builds the release
bundle (§1a), and on `main` installs it on the server. Keep `main` deployable: a red test stops the deploy,
and a bundle that fails its checksum check is refused.
- **Need infra?** Open a Gitea issue titled `infra: …` stating the exact change: a new env var and why,
a mount, a Caddy path that should skip login (e.g. a public webhook endpoint), a new database.
Don't work around the proxy or the firewall.