release-train: develop -> staging - #534
Merged
Merged
Conversation
The guard classified only `client/templates/**` and `client/values.yaml`, but release-helm-chart.yaml packages BOTH `./client` and `./ingestor` (lines 131-132) into one shared index.yaml (line 193). So an unbumped `ingestor/**` edit merged green — the exact dark ship the guard exists to stop (PR #472). Raised by Bugbot on the develop->staging promotion PR #519. Measured on develop: 6 of 9 commits touching ingestor chart content never bumped ingestor/Chart.yaml, whose version has been 0.2.0 since 2026-05-20. Because `helm package ./ingestor` passes no --version override, ingestor's published version IS that file, so those edits did not go nowhere — they overwrote an already-published version. ingestor-0.2.0.tgz was replaced 5x between 2026-05-20 and 2026-07-29 and `helm repo index --merge` refreshed the digest in place, so two installs of "0.2.0" months apart are not the same chart. Helm also caches by version, so an existing client may never pick the change up at all. - derive the guarded chart list from the release workflow's `helm package` lines instead of hardcoding it, so a third chart is guarded on day one - require a bump of the chart's OWN Chart.yaml (bumping client no longer satisfies an ingestor change) - add client/values.schema.json (packaged, and Helm validates user values against it at install time), plus charts/** and crds/** pre-emptively - report every unbumped chart in one run rather than one per push - fail closed when the chart list cannot be read, or when a packaged chart has no Chart.yaml Move the logic into scripts/chart-version-guard.sh so it can be tested: the new scripts/tests/chart-version-guard.bats (23 cases, real throwaway git repo, no stubbed git) runs under the required `Unit tests` check, which this workflow is not. 13 of the 23 fail against the previous inline logic; the 10 that pass on both are the client-side semantics, deliberately unchanged. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Contributor
Author
|
bugbot run |
Contributor
Author
|
👋 Heads-up — Code review queue is at 51 / 30 Above the WIP limit. The team convention is to review existing PRs before opening new work. Open PRs currently in Code review (oldest first):
Pull from review before opening new work. (This is a nudge from the kanban WIP check, not a block.) |
![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 1c86d4b. Configure here.
The Code review WIP limit of 30 was set for a human-paced queue. The column now sits around 50 with items turning over in days, so the nudge fires on nearly every PR and carries no signal. A limit that is always exceeded is noise, not a limit. Nothing gated on this - it never blocked a merge and no required check is affected. Refs: tracebloc/backend#1405
chore(ci): retire the WIP-limit nudge
chore(release): bump chart to 1.9.10 after the v1.9.9 release
Contributor
Author
|
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 e85a0b3. Configure here.
… clamped (bash half of #417) (#445) * fix(installer): memory truth — machine RAM vs Docker's budget as two lines (#417, bash half) Rebuilt on top of #513, which landed the CLAMP half of this work while this PR sat open. #513 already gives every SHOWN figure `_pf_clamp_mem_gb` (physical − PF_OS_RESERVE_GB, floored at PF_MIN_MEM_GB) and hard-fails a sub-floor Docker VM in the post-Docker recheck. This PR's own `_pf_mem_targets` clamp helper is therefore dropped as redundant — it reuses #513's helper instead. What #513 did NOT fix, and this does: the flip-flop. `_pf_total_mem_kb` preferred the runtime view over the host, so the SAME machine reported "16 GB (host)" on a cold run and "6 GB (Docker VM)" on a warm one, purely on whether Docker happened to be running. Two of its tests asserted that behaviour — one was literally named "the Mac trap". - the `_pf_total_mem_kb` memory selector is deleted. Memory has two distinct truths and each caller now names the one it means: `_pf_host_mem_kb` for a hardware fact, `_pf_runtime_mem_kb` for the budget the pods actually get. (CPU keeps its fallback selector — there is no equivalent advice split.) - `_pf_memory` gates on the MACHINE and prints `Memory: N GB (machine)`. The Linux hard-fail gate, the 64 MiB grace and the MemAvailable check are all unchanged. On a machine below the floor the macOS branch no longer offers a Docker resize remedy — no Docker setting fixes too little physical RAM. - Docker's budget becomes its OWN second line via `_pf_runtime_mem_status`, shown only when a runtime is up AND its budget is meaningfully smaller than the machine (the VM case). Native Linux, where the daemon sees all host RAM, no longer repeats the same number twice. - `_pf_hw_summary_line` reports host RAM — it had the same flip-flop in miniature ("7 GB memory" on a 15 GB WSL2 box). - Linux budget hints drop the Docker Desktop dead end (Bugbot #445): a headless box has no Desktop UI, so the remedy names the VM/cgroup limit instead. - `PF_RUNTIME_MEM_WARNED` latches the budget warning so one run never warns twice about the identical condition. It is tested INSIDE the warn branch, never at the top of `_pf_recheck_runtime_mem`, so it can never gate #513's sub-floor hard-fail; a test pins that (latch set + sub-floor VM still exits non-zero). #513's reviewed recheck copy is left exactly as-is. Tests: preflight.bats 89/89 (11 new — the (machine) label, the two-line output, the Linux no-duplicate case, host-unreadable fallback, the clamped/floored advice, both OS hint shapes, the latch, and the latch-can't-gate-the-hard-fail guard; the two Mac-trap selector tests are replaced by a guard that the selector stays gone). Full suite 659/660 — the one failure is `validate_config: valid config passes`, pre-existing on clean develop and macOS-only (the /var symlink; fixed by #443). bash -n + shellcheck --severity=error + check-style clean; manifest regenerated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(installer): one threshold + one copy for the Docker budget; no dead-end advice on a tiny host (Bugbot #445 r2) Two findings from Bugbot on c50df6b, both reproduced and both real. 1) The recheck never actually used the "shared" copy, and graded differently. `_pf_runtime_mem_status` was documented as the single copy for preflight AND the post-Docker recheck, but the recheck still printed its own text — so the COLD install path (Docker starts mid-run, the common case) got no colima guidance on macOS and no hint at all on Linux. Worse, the two compared against different thresholds: the helper against the clamped target, the recheck against the raw PF_WARN_MEM_GB. Measured on an 8 GB host (clamped warn = 6) with a 6 GB budget, one run printed both: ✔ Docker's memory budget: 6 GB ⚠ Docker is running with 6 GB — recommended ≥ 6 GB (6 GB to train) Grading now lives only in the helper, and the recheck calls it. The helper takes MiB so it uses the same PF_VM_MEM_GRACE_MIB tolerance as the recheck — rounding to whole GB first misgraded a VM sized to exactly the documented floor (4900 MiB guest) as sub-floor. A `quiet_ok` flag keeps the recheck silent on a healthy budget, so no run prints the same ✔ twice. 2) A machine too small for the floor was still told to resize Docker. On a 4 GB Mac the budget line advised "colima start --memory 5" — more than the machine has, undercutting the honest "use a larger machine" stop the recheck owns. The helper now detects host − PF_OS_RESERVE_GB < PF_MIN_MEM_GB and points at the machine instead. This mirrors the same fix on the PowerShell side (#444), so both installers now agree on the same hardware. The sub-floor HARD-FAIL is untouched and still unconditional: the latch is tested inside the warn branch only, and a test pins that a set latch plus a sub-floor VM still exits non-zero. Tests: preflight.bats 94/94 (5 new — host-too-small gets no resize, a host that CAN reach the floor still does, the preflight-OK'd budget is never re-warned, the recheck is silent when healthy, and the cold path carries the colima guidance). Full suite 664/665 — the one failure is the pre-existing macOS-only `validate_config` case fixed by #443. shellcheck --severity=error and --warning both clean on preflight.sh; bash -n, check-style and check-drift clean; manifest regenerated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(review): three diverging-copy findings, all closed via one shared predicate Bugbot r3 on #445. All three were the SAME shape as the bug this PR exists to remove — two copies of one judgement disagreeing — surviving on paths the first pass missed. 1. Sub-floor remedy contradicted the hard-fail. On a warm run with a sub-floor budget, _pf_runtime_mem_status hinted "Give Docker <rec>" while _pf_recheck_runtime_mem hard-failed with "raise to <warn>" — the latch suppresses a duplicate warning, deliberately never the hard-fail, so both printed. The remedy now quotes the size that failure quotes; the between-floor-and-warn branch, where no hard-fail follows, still aims at the train figure. 2. Budget GB omitted the VM grace. rt_mib/1024 showed a VM configured at exactly the documented floor as one GB BELOW it — graded correctly by the grace-aware thresholds, displayed as a contradiction. Now (mib + grace)/1024, matching the PowerShell peer. 3. "Enough to run" contradicted "use a larger machine". _pf_memory compared host RAM straight against the Docker floor, ignoring the OS reserve, so a 5-6 GB Mac was graded enough-to-run on one line and told to use a larger machine two lines later. Both now read ONE predicate, _pf_host_too_small_for_floor, which fails safe on unknown input. Native Linux keeps its original wording: the daemon sees host RAM, so the reserve arithmetic does not apply. 696 bats pass (4 new: sub-floor remedy agreement, floor-sized VM display, the machine-line verdict, and the predicate incl. junk input). shellcheck clean; manifest regenerated. * fix(preflight): grace the WARN threshold too, and make the r3 tests enforce Two gaps in 718af66, which otherwise stands as-is — the shared _pf_host_too_small_for_floor predicate is the right shape and is kept. 1. The display became grace-aware but the WARN threshold did not (only the floor one was), so the same self-contradiction reopened one boundary up. Measured on 718af66 with a 32 GB host (warn_eff 8): rt_mib=7680 -> ⚠ budget: 8 GB — recommended ≥ 8 GB rt_mib=8000 -> ⚠ budget: 8 GB — recommended ≥ 8 GB rt_mib=8191 -> ⚠ budget: 8 GB — recommended ≥ 8 GB rt_mib=8192 -> ✔ budget: 8 GB A ~512 MiB band telling the operator to raise a budget to the size it already reports — and Docker Desktop's own defaults land in it. The warn threshold now carries the same grace, so shown == target implies the ✔ branch at BOTH boundaries rather than just the floor. 2. The four r3 tests were only partially enforcing. Under Bats 1.13 a failing bare `[[ ]]` that is not the LAST command in a test body does not fail the test, so `budget: 5 GB`, `!= enough to run`, `Give Docker <warn_eff>` and every line but the last of the predicate test were advisory — they would have passed against broken code. All 16 assertions in those tests now carry `|| return 1`. Verified by mutation, not by inspection: - reverting the warn-threshold grace (i.e. 718af66's shipped state) fails the new boundary test — so this is a real gap, not a hypothetical one; - reverting the display grace fails 2 tests; - neutering _pf_host_too_small_for_floor fails 3, including the r3 predicate test that only became capable of failing once hardened. Baseline and restored are clean in every case. Scope note: only the r3 tests are hardened here. 170 of ~698 tests in this suite share the un-hardened pattern; that sweep needs its own PR because hardening will surface previously-vacuous failures that each need triage (real installer bug vs stale assertion), and burying that in this PR would hide it. Gates: bats scripts/tests/*.bats -> plan 697, ok 697, not ok 0 (complete TAP run); shellcheck --severity=error over the CI file set -> rc=0; check-style clean; check-drift no drift; gen-manifest.sh --check current. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(review): make _pf_memory's thresholds match the grace on its own display Bugbot r5 (High), and correcting my own assumption: the grace on _pf_memory's shown GB came in from develop via the merge, not from my r4 edit. Either way the halves disagreed — the display added PF_VM_MEM_GRACE_MIB while the floor gate kept a 64 MiB tolerance, so a 5 GB VM reporting ~4900 MiB printed "Memory: 5 GB — below the 5 GB the client needs" and, on Linux, hard-failed on it. - floor_mib and warn_mib now use PF_VM_MEM_GRACE_MIB, the same tolerance the display uses and the same one _pf_runtime_mem_status already used for its floor and warn tests. All three now agree on the boundaries. - _pf_host_too_small_for_floor is now fed $(_pf_host_mem_gb) instead of $gb. A shared predicate only prevents divergence if both call sites pass the same input; _pf_memory was passing a grace-adjusted VM-or-host figure while the status path passed raw host GB. MemAvailable is deliberately left ungraced: it is a live measurement, not a configured size, so adjusting it would mask a real shortage. 713 bats pass (2 new: the floor-sized-VM message, and a guard that both call sites feed the predicate the same figure). shellcheck clean; manifest regenerated. * fix(review): render every memory GB through one converter Bugbot r6 found a FOURTH site: _pf_hw_summary_line computed its own memory GB, so the collapsed summary could print a different size from the memory line in the same preflight. Investigating it turned up something worse, and it corrects the record on r4/r5: my r4 fix for _pf_recheck_runtime_mem anchored on a two-line pattern that also existed in _pf_memory, and the replace took the FIRST match — so the fix landed in _pf_memory and the recheck never got it. The grace on _pf_memory's display, which I attributed on the PR to develop via the merge, was actually that misapplied edit. The r5 High finding was a direct consequence. Structural fix rather than a fifth patch: _pf_display_gb_from_mib is now the single definition, used by _pf_memory, _pf_runtime_mem_status, _pf_recheck_runtime_mem and _pf_hw_summary_line. rt_gb goes through it too — it feeds the 'is the VM meaningfully smaller than the machine' comparison, and grading one grace-adjusted side against a raw other side is precisely the mistake these six rounds keep rediscovering. Deliberately still raw: MemAvailable (a live measurement — inflating it would hide a real shortage), disk, and _pf_host_mem_gb (physical RAM needs no compensation, and it is the input _pf_host_too_small_for_floor grades). Every replacement in this commit asserted its anchor matched EXACTLY once and refused otherwise — the guard that would have caught r4's error. 715 bats pass (2 new: a source-level invariant that no site renders its own memory GB, and summary-vs-memory-line agreement). shellcheck clean; manifest regenerated. * fix(review): apply the too-small predicate on every OS in the recheck Bugbot r7 (High). Two divergences in one branch: the reserve arithmetic was inlined instead of calling _pf_host_too_small_for_floor, and the branch was gated OS != Linux while _pf_runtime_mem_status applies it everywhere. On a warm Linux install with a sub-floor cgroup/VM budget, preflight said 'use a larger machine' and this hard-fail then advised raising Docker to a size that machine cannot give. Now calls the shared predicate on every OS, with an OS-appropriate noun so the Mac wording is preserved. Verified both messages agree on a 6 GB Linux host with a 3 GB budget: both say 'use a larger machine'. Same class as r1-r6 on a new axis: not two values disagreeing but two OS GATES disagreeing about when one judgement applies. 717 bats pass (2 new: the Linux path, and an invariant that the reserve arithmetic exists in exactly one place). shellcheck clean; manifest regenerated. --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
…es progress (#532) Two Bugbot findings on the release-train promotion PR client#515. 1. verify-index leaked through its own guard (fail-open). The prerelease check was `printf '%s\n' "$idx" | grep -qF "${TAG#v}"` under `set -o pipefail`: grep -q closes the pipe on its FIRST match, printf takes SIGPIPE and exits 141, pipefail makes the pipeline 141, and the `if` reads a REAL LEAK as "invariants hold". Reproduced at 380KB of index. Same class as the chart-version guard's own SIGPIPE bug. The logic moves to scripts/index-invariants.sh (the chart-version-guard precedent) so it is testable under the required `Unit tests` check, which this release-only workflow is not. Nothing greps a pipe now: every check greps the fetched FILE and branches on grep's own three exit codes -- 0 found, 1 not found, >=2 could-not-check -- and could-not-check fails closed rather than reading as clean. 2. $script:JobInit did not set $ProgressPreference. A fresh job runspace resets it to 'Continue', so PS 5.1 Invoke-WebRequest inside Invoke-WithHeartbeat throttled unless every caller remembered to silence it. Set it in the init script so every runspace inherits it. Tests: new scripts/tests/index-invariants.bats (17) covers both invariants, every fail-closed path, literal-vs-regex tag matching and two "past the 64KB pipe buffer" cases that fail against the old shape. Three Pester cases pin the JobInit silence (runspace, through Invoke-WithHeartbeat, and a source gate that it lives in JobInit itself). manifest.sha256 regenerated for the install-k8s.ps1 edit. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
…533) CLAUDE.md told every author to assign every PR to saadqbal unconditionally. That was true when he was the de-facto code owner for this repo; it is not true now, and it contradicts RFC-BACKEND-0008 D31 (assignee = whoever is doing the work, set by the author) and the org CLAUDE.md. A fixed assignee also re-creates the bystander effect the author-picks model was adopted to remove: if every PR is assigned to the same person, nobody owns any of them. Refs: tracebloc/backend#1405
Contributor
Author
|
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 4846a99. Configure here.
tracebloc-release-train
Bot
added
gate-nudge
…rst-launch prompt (#526) * feat(#430): macOS lifecycle — login autostart, no-admin remedy, first-launch prompt macOS had the weakest lifecycle of the three OSes: no autostart at all (a rebooted headless Mac stayed down until someone re-ran manually), the up-front admin gate failed managed/no-admin users with a generic sudo error, and Docker Desktop's privileged-helper dialog was never mentioned. - _install_macos_autostart: writes a per-user LaunchAgent (no admin needed) that starts the runtime at each login — `open -a Docker` on a GUI Mac, `colima start` on a headless one — with RunAtLoad. Combined with the k3d --restart unless-stopped policy, a rebooted Mac (GUI or headless) returns with ZERO human action. Best-effort; sets TB_MACOS_AUTOSTART=1 so the summary can honestly promise it. - _macos_require_admin (+ _macos_user_is_admin): fail FAST on a no-admin Mac with a named, IT-facing remedy (the macOS analog of Linux prepare-host) instead of preflight_sudo's generic "sudo authentication failed" after a wasted prompt. Admins/root pass through. - First-launch: name the privileged-helper prompt ("macOS asks for your admin password once") alongside the license note, so the auth dialog isn't a surprise. - summary _reboot_note: macOS now says "restarts automatically (login item configured)" when autostart is set; the no-autostart output is byte-identical (golden-safe). Tests: new scripts/tests/setup-macos-lifecycle.bats (admin detection, no-admin remedy, LaunchAgent GUI/headless/best-effort-failure, reboot-note both ways). Separate file from setup-macos.bats / setup-macos-arch.bats to avoid a file-add clash across parallel PRs. shellcheck/style/drift clean; summary + copy-catalog golden green; manifest regenerated. Closes #430 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#430): autostart truly best-effort + accurate no-admin remedy (Bugbot) Two Bugbot findings: 1. (Medium) _install_macos_autostart returns 1 on a mkdir/write failure and install_macos called it BARE under set -e — aborting the whole install after Docker + tools were already in, contradicting the best-effort contract. Call it with `|| true`. New test drives install_macos with a failing autostart and asserts it still exits 0. 2. (High) The no-admin remedy was inaccurate: re-running as the same non-admin account just hits _macos_require_admin again, and there is NO macOS prepare-host (run_prepare_host errors on Darwin). Rewrote it to name the remedies that actually unblock the install — grant THIS account admin rights (then re-run as yourself), or install from an account that already has admin. Dropped the misleading "install Docker + re-run" loop and the nonexistent prepare-host reference. Test updated accordingly. shellcheck/style clean; 10/10 setup-macos-lifecycle.bats; manifest regenerated. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#430): headless autostart via LaunchDaemon + honor TRACEBLOC_NO_AUTOSTART (Bugbot) Two more Bugbot findings: 1. (High) A per-user LaunchAgent only loads inside a GUI/Aqua login session — which a HEADLESS Mac never has — so the headless branch wrote an agent that never runs at boot, making the "restarts automatically" promise false. Headless now installs a system LaunchDaemon (/Library/LaunchDaemons, root) that runs `colima start` at BOOT as the install user, with HOME + PATH set (a boot daemon has no user env). GUI keeps the LaunchAgent. Factored the shared plist skeleton into _emit_launch_plist. 2. (Medium) _install_macos_autostart ignored TRACEBLOC_NO_AUTOSTART, the opt-out that already gates ensure_cluster_autostart (Linux) and the Windows peer. It now short- circuits on that flag, so macOS no longer configures autostart or promises auto- restart when the operator opted out. Tests: headless test now asserts a LaunchDaemon (UserName + EnvironmentVariables + sudo launchctl, boot not login); new opt-out test; GUI + best-effort tests unchanged. 11/11 setup-macos-lifecycle.bats; shellcheck/style/drift clean; manifest regenerated. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#430): per-user autostart log path + accurate reboot note (Bugbot) Two more Bugbot findings on the LaunchDaemon change: 1. (Medium) Both plists logged to a fixed /tmp/tracebloc-autostart.log. With the installer's umask 077 the first account creates it 0600, so a second account's job can't open it (EX_CONFIG → runtime never starts), and /tmp is symlink-plantable on a shared Mac. _emit_launch_plist now takes a per-user log path: the LaunchAgent logs to $HOME/Library/Logs and the LaunchDaemon to the install user's ~/Library/Logs. 2. (Low) _reboot_note said "login item configured" for every macOS autostart, but a headless install uses a system LaunchDaemon (/Library/LaunchDaemons), not a login item — so IT would look in the wrong place. Dropped the mechanism label: "After a reboot, tracebloc restarts automatically." (accurate for both agent and daemon). Tests: assert the plist log path is per-user (Library/Logs), not /tmp; summary + copy-catalog golden green (no-autostart line unchanged). shellcheck clean; manifest regen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#430): headless daemon creates its log dir + resilient boot start (Bugbot) Two more Bugbot findings on the headless LaunchDaemon: 1. (High) The daemon's StandardOutPath is ~/Library/Logs/... but that dir was never created (the GUI path mkdir's its own). On a fresh headless account without ~/Library/Logs, launchd fails EX_CONFIG before colima runs, yet TB_MACOS_AUTOSTART=1 still promised recovery. Now mkdir -p "${_home}/Library/Logs" before writing the plist. 2. (High) The daemon ran a bare oneshot `colima start` at boot with no retry — the VZ+Rosetta stack commonly leaves stale VM state across a reboot, so the first start fails and the edge never comes back. Replaced with a resilient wrapper: /bin/bash -c 'until colima start; retry up to 3x, colima stop + sleep 15 between attempts' — force-stopping clears the stale state. Loop body has no </>/& so it stays valid inside the plist <string>. Tests: headless test now asserts the log dir is created, the /bin/bash resilient wrapper, and colima stop (retry). 11/11 setup-macos-lifecycle.bats; shellcheck/style clean; manifest regen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#430): boot retry uses colima stop --force to clear stale VZ state (Bugbot) The headless LaunchDaemon retry ran a bare `colima stop` between failed starts, but the intent is a FORCE stop: without --force, orphaned VZ driver state isn't cleared (and a bare stop can hang), so all three attempts fail and a rebooted headless Mac stays down despite TB_MACOS_AUTOSTART=1. Use `colima stop --force`. Test asserts the flag. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#430): headless autostart only when colima is the runtime + resolve its real path (Bugbot) Headless autostart always wrote a colima LaunchDaemon and set TB_MACOS_AUTOSTART=1, but install_docker_desktop installs colima only when Docker was DOWN — if Docker was already up by other means colima may be absent, so the daemon was bogus and the auto-restart promise false. The `|| echo /usr/local/bin/colima` fallback also baked a path that's wrong on Apple Silicon (Homebrew there is /opt/homebrew/bin). Now resolve colima via `command -v` (its REAL path on either chip) and, if it isn't installed, skip autostart honestly (best-effort return 1; caller's `|| true`) so the summary won't promise recovery via a runtime that isn't there. New test: headless + colima absent -> skip, no daemon, flag unset. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
Author
|
bugbot run |
tracebloc-release-train
Bot
added
gate-nudge
…tamination (#529) * fix(#459): isolate e2e path 2 from path 1's --reuse-values replay contamination `helm upgrade --reuse-values` records the previous release's COMPUTED values (chart defaults + overrides) as the new release's user-supplied values. Every later --reset-then-reuse-values (the fleet auto-upgrade) then replays those frozen defaults as if an operator set them, so an edge ever hand-upgraded with --reuse-values silently stops receiving chart-default updates — most importantly images.ingestor.prodDigest. e2e-auto-upgrade.sh modelled this on ONE release: path 1 (--reuse-values) contaminated the recorded values, then path 2 (the fleet auto-upgrade) ran on that contaminated release. Path 2's pin assertion passed only because the baseline pin and the working-tree pin coincided — the ERA NOTE tripwire: the first prodDigest bump would trip it. Resolution (issue decision 1 — isolate path 2 from path 1): between the paths, reset the release's recorded values to just the genuine install-time overrides (helm upgrade --reset-values --set clientId/clientPassword/storageClass), so paths 2-4 assert CLEAN-edge auto-upgrade behavior — the fleet's real contract on an edge no one hand-upgraded. Added an assertion using the issue's own contamination fingerprint (`helm get values` WITHOUT --all must not carry the chart-default prodDigest key), and rewrote the ERA NOTE to document the resolution. A contaminated REAL edge stays a separate fleet-audit concern; its remediation is exactly this reset. shellcheck + check-style clean; bash -n ok. (Runs in the label-gated e2e job — needs a real k3d cluster + the published chart, so it's not exercised by default PR CI.) Closes #459 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#459): reset to the PUBLISHED chart for isolation so path 2 stays a real test (Bugbot) The isolation reset targeted $CHART_DIR (the local working-tree chart), so it pre-applied the local chart's new defaults (working-tree prod pin, egress gateway) BEFORE path 2. Path 2 then became a same-version no-op whose live prodDigest / "new defaults flowed" assertions already held from the isolation step — a --reset-then-reuse-values → --reuse-values regression would slip through (computed values would still carry the local pin). Reset to the PUBLISHED chart ($PREV) instead, so path 2 is a genuine published→local upgrade that MUST pull the new defaults for its assertions to pass. shellcheck + check-style + bash -n clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Bugbot, client#534. The verify-index job (added in #532) checked out with bare actions/checkout@v4 and no ref, while all three sibling jobs in this workflow use a SHA-pinned checkout plus ref: github.event.release.tag_name. On a release: published run github.ref intermittently arrives empty (actions/runner#2788), and checkout then falls back to the DEFAULT BRANCH. So the post-publish index backstop would verify the published index using whatever scripts/index-invariants.sh is on develop rather than the one that shipped -- or fail to find it. A backstop reading a different script than the release is worse than no backstop, because it still reports. Now identical to its siblings: same pinned SHA, same ref. Refs: tracebloc/backend#1426
Contributor
Author
|
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 49c65db. Configure here.
tracebloc-release-train
Bot
added
gate-nudge
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 affect release/post-publish CI gates and user-facing install preflight/macOS launchd autostart, but logic is extracted into heavily unit-tested scripts rather than fragile inline shell.
Overview
Release train promotion bundling CI guard fixes, chart 1.9.10, and installer/preflight changes.
Helm release safety: Chart version enforcement moves to
scripts/chart-version-guard.sh(workflow delegates to it), now derives packaged charts fromrelease-helm-chart.yamlso ingestor edits require aChart.yamlbump too, with bats coverage including the large-diff SIGPIPE case. Post-publish index checks move toscripts/index-invariants.sh(file-based grep, no fail-open pipes);verify-indexchecks out the release tag before running the script. WIP limit reusable workflow is removed.CLAUDE.mdupdates PR assignee guidance (author picks assignee, not a fixed owner).Installers: Preflight splits host RAM vs Docker VM budget (
_pf_runtime_mem_status,_pf_display_gb_from_mib), drops_pf_total_mem_kb, and aligns warnings/hard-fails across macOS/Linux (#417/#445). macOS gains admin gate with IT-facing errors, optional login/boot autostart for Docker/colima (TRACEBLOC_NO_AUTOSTART), and summary reboot text when autostart succeeds (#430). PowerShell job init sets$ProgressPreference = SilentlyContinuein every runspace (#515). E2E auto-upgrade resets Helm values between paths so path 2 tests a clean edge (#459).scripts/manifest.sha256updated for touched scripts.Reviewed by Cursor Bugbot for commit 49c65db. Bugbot is set up for automated code reviews on this repo. Configure here.