LotusGuild/matrix
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Dedicated desktop-linux act_runner so Tauri builds stop queueing web CI/deploys #8

New Issue
Closed
opened 2026-09-17 23:24:15 -04:00 by jared · 1 comment
jared commented 2026-09-17 23:24:15 -04:00
Owner
Copy Link
Copy Source

Migrated from LOTUS_TODO.md on 2026-09-17 (the file is now reference-only).

Dedicated desktop-linux runner (infra) — concurrency only collapses burst stacking; a single in-flight build-linux (Tauri, ubuntu-latest) still shares the runner with web CI and can queue a web CI/deploy up to ~30 min. Fix = register a 2nd Linux act_runner labelled desktop-linux (root, network, RAM for a Tauri build; do NOT also label it ubuntu-latest) and point only build-linux: runs-on at it. Relabeling without a matching runner hangs the job forever.

Deferred (chosen-not-now): build-once/deploy-the-artifact to kill the CI-then-deploy double build — revisit only if runner load is still a problem after this.

_Migrated from `LOTUS_TODO.md` on 2026-09-17 (the file is now reference-only)._ **Dedicated `desktop-linux` runner** (infra) — concurrency only collapses _burst_ stacking; a single in-flight `build-linux` (Tauri, `ubuntu-latest`) still shares the runner with web CI and can queue a web CI/deploy up to ~30 min. Fix = register a 2nd Linux act_runner labelled `desktop-linux` (root, network, RAM for a Tauri build; do NOT also label it `ubuntu-latest`) and point only `build-linux: runs-on` at it. Relabeling without a matching runner hangs the job forever. Deferred (chosen-not-now): build-once/deploy-the-artifact to kill the CI-then-deploy double build — revisit only if runner load is still a problem after this.
jared added the infracipriority: medium labels 2026-09-17 23:24:15 -04:00
jared commented 2026-10-25 20:44:24 -04:00
Author
Owner
Copy Link
Copy Source

Fixed on 2026-10-25, without a second runner.

Root cause: the Linux runner (lotus-linux-builder, Docker container gitea-act-runner in CT 119 docker-public on large1) was started without CONFIG_FILE. The gitea/act_runner image only reads a config file when that variable is set, so /data/act_runner/config.yaml, which has said capacity: 4 since August, was never loaded. The runner ran at the default capacity 1, which is why a desktop build held PR checks and deploys for about 30 minutes.

Changes (owner-approved):

  • CT 119: 4 → 8 cores, 4 → 12 GB RAM, applied live (large1 has ~80 GB free).
  • config.yaml: capacity: 2. The job labels now say node:20-bookworm, matching the registration (.runner). The file said bullseye, so loading it as it was would have silently changed the CI image. Backup: config.yaml.bak.2026-10-25.
  • Runner container: recreated with -e CONFIG_FILE=/data/config.yaml, using the same image (sha256:b5c35d6b…, act_runner v0.6.1, not re-pulled), the same mounts and restart policy. It was swapped while no job was running.
  • Rollback: the old container is kept, stopped, as gitea-act-runner-old.

Verified: right after the swap, a desktop build (task 6757) and a PR's CI (task 6755) ran at the same time.

Not affected:

  • The e2e homeserver runs inside each job's own container, so two e2e jobs don't collide.
  • The only host-port step is the Docker image job (-p 8095), which runs on lotus pushes, and those cancel older runs.

I'll delete gitea-act-runner-old once a few runs have passed on the new container.

🤖 Generated with Claude Code

**Fixed on 2026-10-25, without a second runner.** **Root cause:** the Linux runner (`lotus-linux-builder`, Docker container `gitea-act-runner` in CT 119 `docker-public` on large1) was started **without `CONFIG_FILE`**. The `gitea/act_runner` image only reads a config file when that variable is set, so `/data/act_runner/config.yaml`, which has said `capacity: 4` since August, was never loaded. The runner ran at the default **capacity 1**, which is why a desktop build held PR checks and deploys for about 30 minutes. **Changes** (owner-approved): - **CT 119:** 4 → **8 cores**, 4 → **12 GB** RAM, applied live (large1 has ~80 GB free). - **`config.yaml`:** `capacity: 2`. The job labels now say `node:20-bookworm`, matching the registration (`.runner`). The file said `bullseye`, so loading it as it was would have silently changed the CI image. Backup: `config.yaml.bak.2026-10-25`. - **Runner container:** recreated with `-e CONFIG_FILE=/data/config.yaml`, using the **same image** (`sha256:b5c35d6b…`, act_runner v0.6.1, not re-pulled), the same mounts and restart policy. It was swapped while no job was running. - **Rollback:** the old container is kept, stopped, as `gitea-act-runner-old`. **Verified:** right after the swap, a desktop build (task 6757) and a PR's CI (task 6755) ran **at the same time**. **Not affected:** - The e2e homeserver runs inside each job's own container, so two e2e jobs don't collide. - The only host-port step is the Docker image job (`-p 8095`), which runs on `lotus` pushes, and those cancel older runs. I'll delete `gitea-act-runner-old` once a few runs have passed on the new container. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
jared closed this issue 2026-10-25 20:44:25 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something is broken
 ci
CI / workflows
 enhancement
New feature or request
 infra
Infrastructure / runners / servers
 landing
priority: low
priority: medium
security
Security or privacy
 ux
No labels ci infra priority: medium
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
cole (Cole Keller) jared (Jared Vititoe) nathan (Nathan Vititoe)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: LotusGuild/matrix#8