fix(build): `c12d40d` rename severed the profile pipe — every image since 2026-05-05 built profile=sw #46

Merged

triform-admin merged 1 commit from fix/profile-var-rename-severed-x264 into main

2026-07-30 05:47:07 +00:00

triform-admin commented

2026-07-30 05:12:39 +00:00

Owner

capture/build-integration/build.sh cmd_gen read CB_BUILD_PROFILE; the c12d40d cb-*→chromeless rename (2026-05-05) renamed the wrapper's variable — chromeless-build.sh exports CHROMELESS_BUILD_PROFILE — without touching this reader. The export never arrived, :-sw won silently, and every build since — including every deployed cr7727- production image — was gn-gen'd from the base args.gn*: x264_libdir empty, HAS_X264 undefined, H264Encoder compiled as the stub that returns WEBRTC_VIDEO_CODEC_ERROR.

Why 12 weeks of silence: (a) the t7 lane also dropped the unit tests that assert InitEncode works (restored in #45), and (b) the encoder factory fails closed onto libwebrtc's built-in encoders at runtime, so video kept flowing — just never through the x264 path the “x264 profile” images claimed to carry.

Evidence chain (live on triform-7, 2026-07-30):

build log: gn gen out/cb-release (profile=sw, importing …/args.gn) — in a job with CHROMELESS_BUILD_PROFILE=x264 set
H264EncoderTest 7/7 FAILED, InitEncode == −1 (the #else stub)
objdump -p cloud_browser_worker: no x264 NEEDED entry
micro-repro compiling the exact InitEncode param sequence against the staged libx264.so.164 directly: encoder_open OK at 47 threads / 3 threads / finite+infinite keyint / IR on+off — encoder code and library both fine; only the gate was off

Fix: read CHROMELESS_BUILD_PROFILE first, keep CB_BUILD_PROFILE as fallback. Resolution unit-tested for all four set/unset combos; bash -n clean. No C++ changed — but the next t7 build flips HAS_X264 on for the first time since May, and the restored test gate judges it.

🤖 Generated with Claude Code

`capture/build-integration/build.sh cmd_gen` read `CB_BUILD_PROFILE`; the c12d40d cb-*→chromeless rename (2026-05-05) renamed the **wrapper's** variable — `chromeless-build.sh` exports `CHROMELESS_BUILD_PROFILE` — without touching this reader. The export never arrived, `:-sw` won silently, and **every build since — including every deployed cr7727-* production image — was gn-gen'd from the base args.gn**: `x264_libdir` empty, `HAS_X264` undefined, H264Encoder compiled as the stub that returns `WEBRTC_VIDEO_CODEC_ERROR`. **Why 12 weeks of silence:** (a) the t7 lane also dropped the unit tests that assert InitEncode works (restored in #45), and (b) the encoder factory fails closed onto libwebrtc's built-in encoders at runtime, so video kept flowing — just never through the x264 path the “x264 profile” images claimed to carry. **Evidence chain (live on triform-7, 2026-07-30):** - build log: `gn gen out/cb-release (profile=sw, importing …/args.gn)` — in a job with `CHROMELESS_BUILD_PROFILE=x264` set - `H264EncoderTest` 7/7 FAILED, InitEncode == −1 (the `#else` stub) - `objdump -p cloud_browser_worker`: **no x264 NEEDED entry** - micro-repro compiling the exact InitEncode param sequence against the staged libx264.so.164 directly: `encoder_open OK` at 47 threads / 3 threads / finite+infinite keyint / IR on+off — encoder code and library both fine; only the gate was off **Fix:** read `CHROMELESS_BUILD_PROFILE` first, keep `CB_BUILD_PROFILE` as fallback. Resolution unit-tested for all four set/unset combos; `bash -n` clean. No C++ changed — but the next t7 build flips `HAS_X264` on for the first time since May, and the restored test gate judges it. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

triform-admin added 1 commit

2026-07-30 05:12:39 +00:00

fix(build): the c12d40d rename severed the profile pipe — every image since 2026-05-05 built profile=sw

CI / Container smoke test (pull_request) Successful in 7s

Details

CodeQL / Analyze go (pull_request) Has been skipped

Details

CI / Docs link check (pull_request) Successful in 10s

Details

CodeQL / Analyze javascript-typescript (pull_request) Has been skipped

Details

E2E / docker-compose + Playwright (pull_request) Has been skipped

Details

native-peer-gate / native-peer-gate-strict (M7 gate) (pull_request) Successful in 26s

Details

native-peer-gate / native-peer-gate-scaffold (permissive) (pull_request) Successful in 29s

Details

CI / Lint (pull_request) Successful in 58s

Details

bf0bf9df12

capture/build-integration/build.sh cmd_gen read CB_BUILD_PROFILE; the
c12d40d cb-*→chromeless rename (2026-05-05) renamed the WRAPPER's
variable — chromeless-build.sh validates and exports
CHROMELESS_BUILD_PROFILE — without touching this reader. The export
never arrived, ':-sw' won silently, and every build since — including
every deployed cr7727-* production image — was gn-gen'd from the base
args.gn: x264_libdir empty, HAS_X264 undefined, H264Encoder compiled
as the stub that returns WEBRTC_VIDEO_CODEC_ERROR.

Why 12 weeks of silence: (a) the t7 build lane also dropped the unit
tests that assert InitEncode works (restored in PR #45), and (b) at
runtime the encoder factory fails closed onto libwebrtc's built-in
encoders, so video kept flowing — just never through the x264 path
the 'x264 profile' images claimed to carry.

Evidence chain (all live on triform-7, 2026-07-30):
  * build log: 'gn gen out/cb-release (profile=sw, importing
    //cloud-browser/capture/build-integration/args.gn)' — in a job
    with CHROMELESS_BUILD_PROFILE=x264 set
  * H264EncoderTest 7/7 FAILED, InitEncode == -1 (the #else stub)
  * objdump -p cloud_browser_worker: no x264 NEEDED entry
  * micro-repro compiling the EXACT InitEncode param sequence against
    the staged libx264.so.164 directly: encoder_open OK at 47 threads,
    3 threads, finite/infinite keyint, intra-refresh on/off — the
    encoder code and the library are both fine; only the gate was off

Fix: read CHROMELESS_BUILD_PROFILE first, keep CB_BUILD_PROFILE as a
fallback for direct callers that predate the rename. die() message
updated to name the canonical var. Resolution logic unit-tested for
all four set/unset combinations; bash -n clean.

C++ note: this changes no C++ — but the NEXT build flips HAS_X264 on
for the first time since May, so h264_encoder.cc gets its first real
compile+link+test since the API-drift fixes landed. The verify loop
(t7 lane, tests fatal) is what caught this and is what will judge it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>