chadtmiller.com/knotless

Switch repository

Loading…

What changes

The prod host's runner runs two jobs of 3 CPUs and 7 GiB each (--memory 7), up from 6 GiB. deploy.yml and deploy/README.md say so.

Why

Since the runs were capped at 6 GiB, both of the queue's next test pre-flights were killed while compiling knotless-serve for coverage (rustc ended by SIGKILL):

• Admins name agents, and a new triager's warning is no longer dropped, at 8cea0198's first run;
• A branch waits for a review agent's verdict before its pulls land, at c6b66c5a.

The pull that set the cap said to raise it to 7 if this happened. The runner host's test passes at 7 GiB with 4 CPUs.

How it was checked

The deploy writes the new arguments into the host's env file and recreates run. Whether 7 GiB is enough shows in the next pre-flights. The rest is left to CI.

Shortcomings

Two runs at 7 GiB leave about 2 GB of the host's 16 GB for serve, pages and the bots, which use about 1 GB. The 4 GB swap is the margin if both peak at once.

Changeset: none

🤖 Generated with Claude Code

This raises the prod runner's per-job memory cap from 6 to 7 GiB (--memory 7). It updates the comment in deploy.yml and the sentence in deploy/README.md to match. I searched for other mentions of the 6 GiB cap and found none, so the docs are consistent. The change is small and well motivated by the two killed pre-flights. The pull itself names the risk: two jobs at 7 GiB leave about 2 GB, with swap as the margin. That is acceptable, but watch for host pressure after the deploy.