Comparing changes

…gone; disable in-use pruning (#130) Write pruneInUse = false into buildkitd.toml so a customer-run `prune --all --keep-storage` uses upstream leaf-first semantics and can no longer remove a parent layer out from under its children (which leaves DiskUsage with a dangling parent and crashes the daemon). Make shutdownBuildkitd report whether a daemon was actually running: `pkill` exiting 1 means buildkitd already exited, which is not a cleanup failure. The post-step logs the buildkitd tail and continues with sync/unmount and the sticky disk commit; only sync/unmount/flush failures still skip the commit. Drop the stale max-cache-size-mb docs and the unused pruneBuildkitCache helper from the v2 branch; v2 relies on buildkitd GC instead. Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

… success (#133) The VM agent reports commit_early_deny/commit_early_deny_reason on GetStickyDisk when it already knows the commit will be denied (branch protection). Emit a notice at setup, save the reason to state, skip the commit request in the post step, and stop logging a successful commit: the RPC only records intent and the host applies it at VM shutdown. Bumps @buf/blacksmith_vm-agent.bufbuild_es (and its @bufbuild/protobuf peer) to the BSR build that includes the new fields. Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

…k response (#131) * setup_builder: take the buildkitd GC keepDuration from the sticky disk response The backend now attaches buildkitd_config.gc_keep_duration_hours to the sticky disk it hands out (forwarded by the agent on GetStickyDisk), so the GC TTL can be set fleet-wide and per organization without an action release. The action converts the whole-hour value to a BuildKit duration and only overrides keepDuration; gc/all/parallelism keep their defaults. Values outside 1..8760h, non-integers, zero and a missing field fall back to the existing 192h default with a warning where applicable, so older agents and backends keep today's behavior. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * setup_builder: read buildkitdConfig via the generated proto type The pinned @buf/blacksmith_vm-agent.bufbuild_es build already carries BuildkitdConfig, so the structural cast is unnecessary. --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

…n (release/v2) (#128) * export buildkit history and structured lifecycle telemetry at teardown At post-step teardown, export the job's raw BuildKit history records (plus solve-status traces, logs excluded, size-capped) via ListenBuildHistory, delete them so history.db and its content-store attachments are never committed to the sticky disk, and ship them with the runner _diag step timeline and structured lifecycle facts (builder mode/fallback reason, commit decision/skip reason, buildctl du totals incl. per-cache-mount, fs usage, setup/shutdown timings) to the vm-agent's ReportDockerBuild RPC over the shared agent client (BLACKSMITH_AGENT_ADDR discovery). docker_build_ids are issued host-side; all reporting is fail-soft with bounded timeouts and never fails the customer job, and is skipped silently when no agent is reachable or it predates the RPC. BuildKit control and containerd content protos are vendored verbatim from pinned upstream releases (scripts/fetch-protos.sh) and compiled with protoc-gen-es into src/gen; generated code is excluded from eslint. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * chunk docker-build reports to stay under the agent's gRPC recv limit A whole-job report can exceed the vm-agent's default 4 MiB gRPC MaxRecvMsgSize (a 24-build job produces a ~6 MB message that is rejected with resource_exhausted, dropping all telemetry). Builds are split across multiple unary ReportDockerBuild calls with a ~3 MiB per-request budget covering the runner step timeline plus record and trace bytes. The timeline ships in every chunk (workflow-step attribution is per-request server-side); the lifecycle message ships only in the first chunk so the agent never double-emits lifecycle metrics. Per-record/trace caps and fail-soft behavior are unchanged, and each chunk gets its own report timeout. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

…payload cap, and report export caps in the lifecycle (#135) * build-telemetry: finalize pending history records before exporting traces buildkitd writes a build's trace attachment asynchronously, keeping the span recorder open for up to 3s after the record completes. A job whose last build finished just before the post step therefore exported that record without a trace descriptor and then pruned it, so the row landed with trace_missing=1 and no steps. Before collecting, completed records that lack a trace descriptor are finalized via UpdateBuildHistory(Finalize: true), which blocks until the trace is attached (no-op for already-finalized records). Fail-soft with a 5s timeout per record. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * build-telemetry: raise the job-wide history payload cap to 32 MiB The 8 MiB cap predates chunked reporting, when it was the bound on a single ReportDockerBuild request. With ~3 MiB chunks the per-request size is already controlled, so the job-wide cap only decides how many builds of a many-build job keep their traces; at 8 MiB roughly a dozen builds with ~1 MiB traces fit and the rest ship truncated. 32 MiB lets such jobs ship whole while still bounding teardown. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * build-telemetry: report export caps and timeline size in the job lifecycle Every cap that can silently shrink the telemetry is now accounted for in DockerJobLifecycle so absent traces and unattributed builds can be explained from ClickHouse instead of runner debug logs: - timeline_bytes / timeline_truncated: runner step-timeline bytes actually shipped and whether the 1 MiB tail cap cut off the head. - history_export_bytes: record + trace bytes exported across all chunks. - traces_dropped_oversize: traces omitted for a per-build reason (over the per-trace cap or content-store read failure). - traces_dropped_payload_cap / records_dropped_payload_cap: traces, or whole records, omitted because the job-wide 32 MiB cap was reached. Admission to the job-wide cap is factored into admitBuild so the counters are disjoint (a whole-record drop is never also counted as a trace drop) and unit-testable; counters are copied onto the lifecycle only once the export completes, so a timed-out export leaves them at zero. Bumps @buf/blacksmith_vm-agent.bufbuild_es to the BSR commit that carries the new fields. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

Navigation Menu

Repository navigation

Comparing changes

Open a pull request

Commits on Sep 4, 2026

This comparison is taking too long to generate.

Uh oh!