7 Commits

Include renames

Author	SHA1	Message	Date
tfaour	8ae09f238b	Push server image to local registry instead of git.thumeit.com ... Cloudflare (fronting git.thumeit.com) started rejecting image pushes with 413 Payload Too Large once whiteboard mode's Node runtime + native resvg bindings made the image significantly bigger than before. Switched the build/push target to a LAN-local registry (10.0.0.246:3000) that has nothing in front of it to hit that limit, and updated docker-compose.yml.example to match.	2026-07-23 17:10:21 -04:00
tfaour	ad1fa99064	Fix firmware release workflow: build against ESP-IDF v6.0, not v5.3 ... The build container was pinned to espressif/idf:release-v5.3, but the firmware is actually developed against v6.0.2 (this machine's $IDF_PATH). That gap caused real compile failures in CI -- esp_sleep_enable_gpio_wakeup_on_hp_periph_powerdown and ESP_NETIF_CAPTIVEPORTAL_URI are both newer than v5.3 has, plus a transitive stdbool.h include that changed between versions -- none of it a real bug in the source.	2026-07-21 21:41:36 -04:00
tfaour	ecc5b8d197	Fix firmware release workflow: docker cp instead of a bind-mount ... The runner's job workspace lives in a named Docker volume, not a real host path, so a nested docker run -v "\$PWD:/workspace" bind-mounted an empty directory when talking to the host daemon (which has no notion of paths inside the calling container) -- build_for_board.sh: No such file or directory. docker create/cp/start streams the checkout into the build container through the Docker API instead, which works regardless of what backs either side's workspace.	2026-07-21 21:35:30 -04:00
tfaour	9e630c0c6e	Fix firmware release workflow: run checkout outside the ESP-IDF container ... espressif/idf:release-v5.3 has no Node.js, and actions/checkout (a Node action) runs inside whatever container: the job specifies -- it failed immediately with "node: not found" on the first real run. Checkout now runs on the plain runner; only the two build steps spin up the ESP-IDF image themselves via docker run, using the runner's already-mounted docker socket.	2026-07-21 21:32:00 -04:00
tfaour	94d67f7767	Firmware CI releases + Gitea auto-update in the server ... New Gitea Actions workflow builds both board variants and publishes them as release assets whenever firmware/version.txt is bumped. The server can now poll that repo's releases (next to the existing manual upload) and either surface an "Update frame" button or, with "Automatically apply updates" checked, stage the new build itself -- the frame still only updates on its own next wake either way.	2026-07-21 19:25:08 -04:00
tfaour	2cd7283ce9	Fix Gitea Actions registry auth: use a PAT instead of the auto token ... The automatic GITHUB_TOKEN doesn't reliably authenticate against Gitea's Container Registry -- confirmed as a known, still-open limitation across several Gitea versions (multiple upstream issues, consistent with the 401/unauthorized error hit here). Gitea's own community guidance is to use a real Personal Access Token instead. Switches docker/login-action to a REGISTRY_TOKEN repo secret (a PAT with package write scope, created in Gitea's user settings) with an explicit username rather than the gitea.actor context, and drops the now-unused permissions: packages: write block that only applied to the auto token.	2026-07-18 15:50:11 -04:00
tfaour	1c1d9c6767	Add Gitea Actions workflow to build/push the server image ... Builds server/Dockerfile and pushes to this repo's Gitea Container Registry (git.thumeit.com/tfaour/espresso-frame-server) on every push to main that touches server/, tagged both latest and the commit SHA. docker-compose.yml now sets both image: and build: -- deploy hosts can docker compose pull to grab the CI-built image without needing this repo's build context, while local dev can still docker compose build against Dockerfile changes directly.	2026-07-18 14:38:55 -04:00