Skip to content

release-train: develop -> staging - #1050

Merged
tracebloc-release-train[bot] merged 3 commits into
stagingfrom
release-train/to-staging
Sep 11, 2026
Merged

release-train: develop -> staging#1050
tracebloc-release-train[bot] merged 3 commits into
stagingfrom
release-train/to-staging

Conversation

@LukasWodka

@LukasWodka LukasWodka commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

Automated promotion by the release train (RFC-0008 D14). Head is the train-managed release-train/to-staging branch (a mirror of develop), 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: resourceMonitor moves from a boolean to resourceMonitor.enabled, with a single tracebloc.resourceMonitorEnabled helper 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_args and applies them in a dedicated kubectl annotate before 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 new image-refresh-latched-annotate.bats lock ordering and separation from annotate_args.

Mirror publish fails the gitleaks install step if GITLEAKS_SHA256 is 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.

aptracebloc and others added 3 commits September 11, 2026 09:38
…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>
@LukasWodka

Copy link
Copy Markdown
Contributor Author

bugbot run

@saqlainsyed007
saqlainsyed007 removed the request for review from saadqbal September 11, 2026 09:29

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ 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.

@tracebloc-release-train tracebloc-release-train Bot added gate-nudge Toggled by the release train to (re-)fire the fr-gate and removed gate-nudge Toggled by the release train to (re-)fire the fr-gate labels Sep 11, 2026
@tracebloc-release-train
tracebloc-release-train Bot merged commit 209575a into staging Sep 11, 2026
45 checks passed
@tracebloc-release-train
tracebloc-release-train Bot deleted the release-train/to-staging branch September 11, 2026 13:13
@LukasWodka

Copy link
Copy Markdown
Contributor Author

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 FR on staging — backend 17, design-system-v2 11, tracebloc-engine 9, e2e-test-agent 9, frontend-app 8, tracebloc-py-package 5, org-config 5, cli 5, tracebloc-website 4, client 4, .github 4, docs 3, client-runtime 3, quickstart 2, design-system 2, data-ingestors 2 — advance to Ready for prod. This batch includes org-config's and quickstart's first-ever promotions through the train.

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: model-zoo was renamed to model-zoo-archive during today's org restructuring, and five e2e-test-agent workflows still hardcode the old checkout path — every leg died at "Fetch the model the journey trains" before reaching admission or Train. Already fixed on develop (e2e-test-agent#625) but not yet promoted to staging. A second pass was dispatched on develop's ref (carrying the fix) while still installing the staging candidate chart, to avoid recutting staging and expanding this batch's scope mid-review. Those runs were still in their Train step, verdict not yet landed, when the reviewer instructed proceeding regardless. This record does not claim a positive training-path verdict for this batch; it is stated here for the record rather than omitted.

What was independently confirmed clean before that decision:

  • Channels (fr-assist, run 34603176353, 13:14 UTC): all OK, one skipped for credentials.
  • Per-repo staging CI green on every tip at review time: backend Tests/docker-build/Lint/Migrations; client CodeQL/E2E mysql/E2E auth-proxy/Release Helm Chart; client-runtime Publish images/Tests; design-system(-v2) Tests/Publish to GitHub Packages; frontend-app Tests + staging smoke (run 34609086840, green); tracebloc-py-package Test Suite + TestPyPI rc; cli CodeQL/Release; tracebloc-website; docs/.github CodeQL/Selftests; data-ingestors CodeQL/Publish internal images; org-config Selftests.
  • Engine's staging tip carried a cancelled post-merge test (3.11) run, superseded by the PR's own pre-merge required-check pass (gate SUCCESS, Bugbot SUCCESS per the train's merge log) plus the same commit's vision-cv-slim-deps succeeding independently — not a live regression.
  • All 93 PR bodies read for holds, interactive/TTY behaviour, or unshipped breaking changes: every flagged phrase (Storybook's "interactive" story, a TypeErrors substring match, stale "not yet merged" text about an already-merged PR, unchecked template checkboxes, mutation-test prose using "revert") was a false positive on inspection. No genuine hold found.
  • e2e-test-agent's Unit tests red on staging (also model-zoo-rename fallout, same fix(#562): soften API-wait and readiness timeouts for slow/proxied laptops #625 fix) is unrelated to any of the 93 tickets' own code.

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); client-runtime#553's GPU decline-fallback logic (no GPU in the CPU journey, unchanged from prior batches).

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

gate-nudge Toggled by the release train to (re-)fire the fr-gate

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants