Check-in — 2026-08-22 runner 2.336.0 rollout
TL;DR
The GitHub Actions fleet now uses runner 2.336.0 and image r5 across
all six placements. General and Docker placements were drained, upgraded, and
resumed without runner loss. Live image labels match the manifest version and
SHA-256 pin.
Phase status
| Item |
Status |
general-a / general-b |
Upgraded and resumed |
docker-a / docker-b |
Upgraded and resumed |
lan-a / mgmt-a |
Pinned image verified |
| Late PR #317 runners |
Both general runners upgraded; Docker runner covered |
| GitHub App Client ID migration |
Done 2026-08-22 |
What shipped
- General placement upgrades completed through fleet operations:
general-b run 32568184667
and
general-a run 32569604364.
- Docker placements used the same guarded drain → upgrade → resume contract
through the direct WSL-to-Windows SSH tunnel, avoiding repeated dispatcher
startup overhead.
- Every placement exposes image labels
org.opencontainers.image.version=2.336.0 and
app.github.runner.sha256=04cf0be1…505d5d.
- PR #317 merged during the rollout. Its two general runners were handled as
exact targets after the placement runs; its Docker runner was included in
the Docker host pass.
Known gaps / drift
- The dispatcher is safe but slow for placement rolls: each operation starts
LAN validation, wakes the ephemeral management runner, and applies serially.
- The WSL SSH tunnel config was missing
gha-docker-a; the local operator
config now includes 172.29.240.13.
- GitHub App fleet workflows use
client-id + RUNNER_FLEET_*_CLIENT_ID.
What remains
| Who |
Work |
Priority |
| (done) |
GitHub App Client IDs + workflow client-id switch |
Done |
| Later |
Reduce safe dispatcher setup latency for placement operations |
P3 |
flowchart LR
manifest["fleet.yml<br/>2.336.0-r5"] --> drain[Graceful drain]
drain --> general[General A/B]
drain --> docker[Docker A/B]
general --> verify[Version + SHA verification]
docker --> verify
lan[LAN] --> verify
mgmt[Management] --> verify
verify --> resume[All runners resumed]