`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>
desktop-test runs the 39 desktop tests in the backend venv (an absolute
path, so pytest does not warn about sys.prefix); the root README explains
that a '*' in the expansion list means every subdomain, and that the desktop
app answers the zones a hosts file cannot express.
Three pieces so kadence.timka.su can be stood up and updated from the repo
rather than from shell history on the box:
* `docker-compose.prod.yml` — publishes the app on loopback only. The base
file's `${APP_PORT}:8000` binds every interface, which on this host both
collides with remnawave (already on 8000) and would serve the API beside
the proxy without TLS. Compose *appends* merged port lists, so the override
needs the `!override` tag or the public binding survives. uvicorn also gets
`--proxy-headers`, without which every request looks like plain HTTP from
127.0.0.1 and the session cookie loses its `Secure` flag.
* `deploy/nginx/kadence.timka.su.conf` — TLS, HSTS, the forwarded headers the
cookie logic reads, and a 120s read timeout because one task refresh fans
out to four third-party APIs.
* `deploy/deploy.sh` — idempotent install-or-update. Generates API_TOKEN and
the database password once and never rotates them afterwards (that would
lock out the phone and the desktop app), treats `.env.example`'s
`change-me` placeholders as unset, and uses `certbot certonly --webroot`
rather than `--nginx` so the vhost in git stays the truth.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
timka123andClaude Opus 5