From 62c5ec55e11ddcaa02cdd91211b90b15894a2264 Mon Sep 17 00:00:00 2001 From: Waleed Latif Date: Mon, 10 Aug 2026 13:53:18 -0700 Subject: [PATCH] docs(ci): correct the app-image runner sizing rationale with measured numbers The comment justified 16 vCPU by claiming both dominant steps scale with cores. Only one does. Measured across two runs that restored the same sticky-disk parent snapshot, so runner size was the only variable: [builder 5/6] next build 490.5s -> 143.9s (3.4x) [deps 4/4] bun install+gyp 465.3s -> 547.2s (no gain) The deps layer is a bun install plus a node-gyp rebuild pinned to JOBS=4 to avoid an OOM, so cores cannot help it. This matters because end-to-end duration says the opposite. The deps layer misses the Docker cache on nearly every run, and that ~500s swing swamps the 3.4x -- the one 16 vCPU sample (965s) lands mid-spread of the 8 vCPU samples (766/778/1020/1167s), which reads as "no win" and invites a revert that would throw away a real one. The miss is upstream: all five image builds share one Blacksmith sticky disk (setup-docker-builder keys it on GITHUB_REPO_NAME alone), so consecutive app builds restore the same parent snapshot and each one's cache commit is discarded. Comment-only; no behavior change. --- .github/workflows/ci.yml | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 4940a8d6b34..d9582546e2a 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -159,12 +159,17 @@ jobs: # 16 GB one (exit 137). The others build in <5 min and idle at 12-15% # CPU on 8 vCPU, so they stay on the smaller tiers. # - # 16 vCPU on Blacksmith because this build is the critical path to a - # deploy — nothing ships until the image is pushed — and its two - # dominant steps both scale with cores (`bun install` ~300-400s, `next - # build` ~260s). The same `next build` runs on 16 vCPU in the separate - # Build App verification job, which does not gate anything; this one - # was doing comparable work on half the cores. + # 16 vCPU: this build gates every deploy, and `next build` scales with + # cores — 490.5s to 143.9s, measured across two runs that restored the + # same sticky-disk snapshot, so runner size was the only variable. The + # deps layer does not scale (465.3s to 547.2s): it is `bun install` + # plus a node-gyp rebuild pinned to JOBS=4. Size this on `next build`. + # + # Size it on step times, never end-to-end: deps misses the Docker cache + # on nearly every run, and that ~500s swing hides the 3.4x. All five + # image builds share one Blacksmith sticky disk (the action keys it on + # GITHUB_REPO_NAME alone), so consecutive app builds restore the same + # parent snapshot and each one's cache commit is discarded. - dockerfile: ./docker/app.Dockerfile ecr_repo_secret: ECR_APP gh_runner: linux-x64-8-core