`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>
`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>
Four workflows, none of which existed:
* `tests.yml` — backend, desktop, `:core` and the web app's typecheck+build, in
parallel. `:core` needs no Android SDK at all, because settings.gradle.kts
leaves `:app` out when there is none; `:app`'s Robolectric suite therefore
lives in the APK workflow, where the SDK is installed anyway. Nothing needs a
running backend — the suites feed on committed fixtures, which is the whole
reason they were written that way.
* `lint.yml` — ruff, which the repo had been configured for and never run.
* `docker.yml` — builds the image, *starts* it against SQLite and waits for
/api/health before pushing, then publishes `:latest` and `:<short-sha>` to
git.timka.su. A tag nobody can run is worse than no tag.
* `android-release.yml` — the release APK on every push to master, signed from
secrets, with `apksigner verify --print-certs` reporting which key was really
used and failing if it was the debug one.
Three things the repo needed before any of that could work:
`versionCode` was pinned at 1, so every APK looked like the same version to the
phone and would not install over its predecessor. It now comes from the run
number, with `versionName` from a property, both via one `setting()` helper that
reads a Gradle property or an environment variable.
The release build fell back to the *debug* signing key whenever the keystore was
missing — silently. That is a trap: the APK installs, looks fine, and can never
be upgraded by a properly signed build. `KADENCE_REQUIRE_SIGNING=1` makes that
case fail the build instead, and the release job sets it whenever a keystore
secret is present.
The compose files built an image with no name, so there was nothing to pull.
`image:` now names the registry tag while `up --build` still builds locally.
Also: `android/ci/install-sdk.sh` (idempotent, cacheable, and the one place that
knows `platforms;android-37.0` is spelled with the minor version), the runner as
a compose service with its config and a setup checklist, six make targets, and a
README section. No runner is registered yet — `make ci-runner` is step two of
that checklist.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
timka123andClaude Opus 5