4 Commits

Include renames

Author	SHA1	Message	Date
timka123	894f132e34	fix ots	2026-10-22 21:58:57 +03:00
timka123	1bdd65cc76	implement ota updates	2026-10-22 21:11:04 +03:00
timka123andClaude Opus 5	4584a5324d	ci: an empty docker_host is how 0.3.x mounts the socket into jobs ... `docker_host: automount` is a later act_runner's spelling of the default, and 0.3.1 does not know the word: it exits with `unable to parse docker host automount` and restart-loops — registered, visible in Gitea, never online, and the logs say nothing about the config file. On 0.3.x the empty value is the one that finds a daemon *and* passes it to the job containers, which is what `docker.yml` needs; `"-"` is the value that withholds it. Both spellings are now in the guide's failure table, because the symptom points at the daemon rather than at the one word that caused it. Verified in the job image on the runner host: Ubuntu 24.04 as root, node 24, Python 3.12.3, npm, curl and unzip (the SDK script's dependencies), apt-get update/install, `python3 -m venv` plus pip, `docker version` against the host's 27.5.1 through the mounted socket, and openjdk-21-jdk-headless landing exactly at the `JAVA_HOME` the Android jobs assume. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-22 18:42:25 +03:00
timka123andClaude Opus 5	8415c8995b	ci: the runner is docker-mode, and a guide for setting one up ... `runs-on: ubuntu-latest` stays what it is everywhere else — a disposable container — and `docker-compose.ci.yml` is now what makes that true: the label maps to `catthehacker/ubuntu:act-24.04`, job containers share the runner's network so the cache server is reachable at all, and the host's docker socket is passed through (`docker_host: automount`) so the image workflow can build. The failure this is replacing is worth naming, because the symptom does not point at it: with a **host**-mode runner answering the same label, every job runs directly on the server as the runner's own user, so the workflows' `apt-get install` steps fail on permissions — and had they succeeded, CI would have been installing packages on a host. A workflow cannot tell which kind of runner it got; only the label map can say. `docs/gitea-runner.md` is the separate guide: why docker mode, the prerequisites including Gitea's two `app.ini` settings, the install, how to remove a host-mode runner (and what to check before you do, since a runner is shared), how to verify a job really is in a container, why labels cannot be changed without re-registering, and a table of the failures with their causes. Also `workflow_dispatch` on the test workflow, so a fresh runner can be proved from the UI without inventing a commit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-22 18:35:20 +03:00