From fd1812e1613195a57ff045e6b5646ed92d51649a Mon Sep 17 00:00:00 2001 From: Suriyakumarvijayanayagam Date: Mon, 31 Aug 2026 11:13:47 +0530 Subject: [PATCH] Record the CI runner, now that one exists MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Both repositories carried GitHub Actions workflows on a Gitea remote and nobody had confirmed a runner. There was not one: the 924 frontend checks, the whole Go suite, the skip guard and the suite-shrank guard had never run on a push, only when somebody remembered. gitea/act_runner v0.6.1 is registered as krow-runner on the cluster host. This commit is also the first push that can prove it picks up a job, which is the failure mode worth catching — a runner that registers and never runs anything looks identical to a healthy one in the Runners list. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01PJvibeSc1JYXjatankqM1g --- docs/handover.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/docs/handover.md b/docs/handover.md index 753f511..717fdfa 100644 --- a/docs/handover.md +++ b/docs/handover.md @@ -174,9 +174,17 @@ course, not a position in a window. CI against the target database" is still aspirational. - The fixture-drift CI jobs need `FRONTEND_REPO_TOKEN` to see the sibling repo, and fail rather than pass quietly without it. -- The remote is Gitea. These are GitHub Actions workflows; they do nothing until - a compatible runner exists. Nobody has confirmed a runner exists, so treat - both repositories as having no CI until somebody checks. +- The remote is Gitea and the workflows are GitHub Actions syntax. Gitea Actions + runs them, and a runner now exists: `gitea-runner` (gitea/act_runner v0.6.1) + on the cluster host, registered as `krow-runner` with labels + `ubuntu-latest, ubuntu-22.04` mapped to `node:20-bookworm`. Before that, both + repositories had workflows that had never executed once — the 924 frontend + checks, the whole Go suite, the skip guard and the suite-shrank guard were + all things somebody had to remember to run. + + If a job fails resolving `actions/checkout` or `actions/setup-node`, the + runner needs egress to github.com or a mirror; that is where those actions + come from and Gitea does not host them. - **The application talks to its database in clear text.** `DATABASE_SSLMODE= disable` against `66.116.207.225`, which is a DIFFERENT machine from the cluster host — so credentials and every row cross the network unencrypted.