release-train: develop -> staging - #1050
Conversation
…D2) (#1016) * [settings-naming] rename resourceMonitor -> resourceMonitor.enabled (D2) RFC-0076 S14 (client#1009). `resourceMonitor: <bool>` becomes `resourceMonitor.enabled: <bool>` (D2: component booleans are `<component>.enabled`). This is a bool->object change, so every stored values.yaml and every `--set resourceMonitor=true` still arrives as a SCALAR. A template that read `.Values.resourceMonitor.enabled` blindly would `fail` ("can't evaluate field enabled in interface {}") on the scalar, and the old `ne .Values.resourceMonitor false` gate crashes ("incompatible types for comparison: map and bool") on the new object. So all reads now route through a single new helper, tracebloc.resourceMonitorEnabled, which resolves the effective flag from whichever shape is present (kindIs), preferring the new `.enabled` form and defaulting absent/`{}` to enabled to match the historical default. Effective behaviour is unchanged: resourceMonitor.enabled=true does exactly what resourceMonitor=true did. - values.yaml default is now the object form; legacy scalar still honoured through the alias window (remove_by: 2026-12-31). - values.schema.json accepts both a boolean and an object; the object CLOSES its keys (additionalProperties: false) so a mistyped `enabled` is refused at chart load instead of silently staying enabled. - migrated the eight readers (daemonset, rbac, scc, secrets, rbac.yaml, jobs-manager NODE_AGENTS_NAMESPACE, NOTES.txt, and the two _helpers predicates resourceMonitorRefreshPinned / nodeAgentsInUse). - Chart.yaml version+appVersion bumped 1.9.107 -> 1.9.108 (chart-version-guard). - helm-unittest: added legacy-scalar, new-object, unset, null, `{}`, both-disabled, and mistyped-key cases. Closes #1009 Part of tracebloc/backend#3391 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * chore(chart): bump to 1.9.109 (one patch above develop, chart-version-guard) — client#1009 Develop advanced to 1.9.108 after this branch bumped there too; re-bump so the version stays above develop. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
…tart block (#1039) The #563 flap guard does WARN + FLAP_KEY + exit 0 once refresh-attempt >= MAX_REFRESH_ATTEMPTS, before the end-of-tick digest annotate. The stale-pin clears were batched into that final annotate, so on a tick that is both off-digest (restart_needed=1) and latched they were dropped, leaving a false "pin is stale" finding to persist. Move the stale-pin writes (clears + finding-set) into their own accumulator, annotated in a bounded, non-fatal call above the restart block. They touch only stale-pin-<image> keys, never last-refreshed-<image>-digest, so writing them before the rollout can't affect the recorded==latest skip; the digest record stays below, after a successful rollout. Tests: image-refresh-latched-annotate.bats (new, extracts the shipped tail and asserts the clear lands while the digest record does not on a latched tick, and both land on a healthy tick); image-refresh-stale-pin.bats harness updated for the accumulator; image_refresh_test.yaml render guard covering all four stale-pin writes on both axes. Split from #1008 (item 2). Bumps chart to 1.9.117.
… sha256sum -c (backend#3676) (#1047) A mangled, empty, or truncated pin piped straight into `sha256sum -c` can pass verification: coreutils reports a malformed checksum line as "no properly formatted checksum lines found", and whether that is a non-zero exit is build-dependent (GNU exits 1; some builds exit 0). So a bad pin can let an UNVERIFIED gitleaks binary get extracted and run, defeating the point of pinning the scanner. Add the same fail-closed hex-digest guard the kubeconform install already uses in helm-ci.yaml, adjusted for this variable and placed right after the curl download and before the sha256sum line, inside the existing set -euo pipefail block. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
|
bugbot run |
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 865edcc. Configure here.
Functional review — staging batch of 2026-09-11 (93 cards, multiple hops today) — PASS at reviewer's explicit instruction (FR reviewer: LukasWodka; self-signoff per RFC-BACKEND-1405 D6)Decision: PASS. All 93 cards at Note on the journey verdict. Three candidate baselines (tabular/image/text_classification) were dispatched on the staging candidate chart (v1.9.117-rc.1) to prove training end-to-end. The first pass, run on staging's own harness, could not complete: What was independently confirmed clean before that decision:
Not independently verified: the training-admission path on the exact staging chart via staging's own harness (superseded by the develop-ref run described above, which had not reached a verdict); What this evidence cannot tell you (README → Functional review): per-ticket behaviour beyond the journey's path, anything after a failing step, and steps a run skipped. |
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
Helm value-shape migration and image-refresh annotation timing affect upgrades and edge auto-refresh behavior; changes are backward-compatible but touch RBAC, DaemonSet gating, and CronJob logic across the chart.
Overview
Helm client chart 1.9.117 introduces RFC-0076:
resourceMonitormoves from a boolean toresourceMonitor.enabled, with a singletracebloc.resourceMonitorEnabledhelper so legacy scalars,--set resourceMonitor=true, and the new object all behave the same through the alias window (remove_by 2026-12-31). DaemonSet, RBAC, secrets, jobs-manager env, image-refresh pinning, and NOTES now gate on that helper; schema accepts bool or object and rejects mistyped keys.Image-refresh (#1008) routes stale-pin annotation clears/sets through
stale_pin_argsand applies them in a dedicatedkubectl annotatebefore the restart/flap-guard block, so latched ticks no longer drop diagnostic stale-pin updates while still recording digest annotations only after rollout. Unit tests and newimage-refresh-latched-annotate.batslock ordering and separation fromannotate_args.Mirror publish fails the gitleaks install step if
GITLEAKS_SHA256is not a full 64-character hex digest, avoiding silent no-op checksum verification.Reviewed by Cursor Bugbot for commit 865edcc. Bugbot is set up for automated code reviews on this repo. Configure here.