release-train: develop -> staging - #462
Conversation
…lent GPU pass (.github#457) (#459) * fix(dead-weight): unresolved base-image ARG is cannot-parse, not a silent GPU pass (backend#3562) `_stage_gpu_map` discarded the unresolved flag from `_expand_args` and ran GPU_HINT on the raw FROM text. An unset `ARG` whose name contains cuda/gpu/ nvidia/rocm (e.g. `FROM ${CUDA_IMAGE}`) therefore matched GPU_HINT via its own placeholder name, marked the stage GPU, and cleared the `cuda-torch-on-cpu` finding without knowing the image -- the same ambiguity check_full_python_base already reports as `cannot-parse`. - Judge GPU-ness on the resolved text only (strip unresolved `${ARG}`), so a placeholder name can't spuriously satisfy GPU_HINT; a tag-only placeholder over a real GPU name (`nvidia/cuda:${TAG}`) is still GPU. - Thread the unresolved flag through `_stage_gpu_map`/`_installers_of`; an install in an unresolved-base stage is now `cannot-parse` (scan integrity), not a silent clean pass. - Selftest cases + mutations for the new behaviour; re-anchor the mutations whose source lines moved. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(dead-weight): treat any placeholder left after ARG expansion as unresolved (backend#3562) Bugbot (.github#459): `_expand_args` does not recurse into a nested default like `${IMAGE:-${GPU_BASE}}`, so the inner `${GPU_BASE}` survives expansion; the GPU-strip then discarded it and the stage read as a known CPU image, raising a false `cuda-torch-on-cpu` instead of `cannot-parse`. Use ANY placeholder still present after expansion (`ARG_REF.search(ref)`) as the unresolved signal, not just `_expand_args`'s non-recursive flag. Selftest case + mutation for the nested-default path. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(dead-weight): cite the public thread; judge unknown base on empty resolved NAME (.github#457) Review (.github#459): this is a public repo, so drop the private-tracker citations -- code comments now reference .github#457 (the public Bugbot thread). Also adopts the reviewer's nit: an image is "unknown" only when expansion leaves no resolvable image NAME, not when any placeholder remains. A name templated only in its registry or tag (`${REGISTRY}/python:3.11-slim`, `nvidia/cuda:${TAG}`) is known -- the registry-prefix case is a normal cuda-torch-on-cpu finding with the real "+cpu / index" remedy again, not a false cannot-parse. Nested defaults and fully-templated names (`${IMAGE:-${GPU_BASE}}`, `${CUDA_IMAGE}`) stay cannot-parse. Moved the CPU-via-ARG counter-assertion beside its GPU twin. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Syed Saqlain <syedsaqlain@MacBook-Pro.local> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
|
bugbot run |
tracebloc-release-train
Bot
added
the
gate-nudge
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 2645c82. Configure here.
tracebloc-release-train
Bot
removed
the
gate-nudge
Functional review — staging batch 2026-09-10 (10:43 hop): HELD, not passedEvidence pulled 11:56–12:20 UTC against these tips: fr-assist channels all OK (1 SKIPPED, credentials); frontend smoke on The cause is not this batch: it is chart v1.9.109 (tracebloc/client#1017, kubelet reservation) combined with client-runtime's v3 envelope contract (tracebloc/client-runtime#544), both already on No card from this batch advances until the journey trains again on the corrected chart. No prod hop until then. |
Functional review — staging batches of 2026-09-10 (10:43 and 14:49 hops) — PASS (FR reviewer: LukasWodka; self-signoff per RFC-BACKEND-1405 D6)Decision: PASS, by the reviewer's instruction at 15:45 UTC. All 132 cards that sat at What changed since the hold. The 12:00 hold was not about this batch: the edge refused every training envelope with Evidence at signoff.
Things this evidence cannot tell you (README → Functional review): interactive/TTY behaviour, per-ticket behaviour, anything at or after a failing step, and any step a run skipped. |
|
Correction to the evidence paragraph above (15:50 UTC). The two journey runs named there (34497041338, 34497050908) were dispatched with |
|
Journey verdict appended (16:20 UTC) — the fix is confirmed on staging's candidate chart.
Same node, same runtime image, same envelope; only the chart differs. The published chart (prod) still refuses; the candidate admits and trains to completion. Prod hop proceeds so 1.9.112 supersedes 1.9.109. |
2 participants
Automated promotion by the release train (RFC-0008 D14). Head is the train-managed
release-train/to-stagingbranch (a mirror ofdevelop), so it never collides with a human PR. Merged only when the fr-gate is green.Note
Medium Risk
Changes gate behavior for Dockerfiles with parameterized bases: some repos may newly fail CI with cannot-parse until ARG defaults are set, but avoids silently missing CUDA-on-CPU torch issues.
Overview
dead-weight
cuda-torch-on-cpu: Dockerfile stage GPU/CPU detection no longer treats unsetFROM ${ARG}references as GPU when the ARG name containscuda, and no longer silently skips those installs._stage_gpu_mapnow tracks per-stage unresolved base images (no resolved image name after ARG expansion). GPU hints are evaluated on stripped refs so placeholder text cannot fake a GPU stage. Stages with only a known name but an unset tag/registry (e.g.nvidia/cuda:${TAG},${REGISTRY}/python:3.11-slim) stay classifiable; truly unknown bases (bare${CUDA_IMAGE}, nested defaults like${IMAGE:-${GPU_BASE}}) are flagged.Pip installs in an unresolved, non-GPU stage emit a
cannot-parsescan-integrity finding (fail closed, likefull-python-base), instead of a clean pass or a falsecuda-torch-on-cpuhit.Tests: New selftest cases and mutation anchors cover unset ARGs, nested defaults, registry-only placeholders, and the cannot-parse path.
Reviewed by Cursor Bugbot for commit 2645c82. Bugbot is set up for automated code reviews on this repo. Configure here.