…ig for v2 (#108)

* feat: add required cache-key input for v2

Replace the hardcoded GITHUB_REPO_NAME sticky disk key with a required
cache-key input. Users must explicitly declare which cache entity their
build targets, preventing cache thrashing in multi-target repos.

The cache-key is saved to action state and passed through to the commit
phase so the same key is used for both expose and commit RPCs.

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* feat: replace manual pruning with buildkit native gc

Remove max-cache-size-mb input and manual buildctl prune from the post
phase. Enable BuildKit's native garbage collection with a time-based
policy (keepDuration=192h / 8 days). Layers unused for longer than the
retention period are automatically cleaned up; active layers survive
indefinitely regardless of total cache size.

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* feat: add server-driven config infrastructure for GC and pre-commit hooks

Add BuildkitdConfig and PreCommitHook interfaces (server-config.ts) that
define the contract for server-driven cache lifecycle management. The
action reads BuildkitdConfig from the GetStickyDisk RPC response (with
hardcoded fallback for Phase 1) and runs pre-commit hooks from the
PrepareCommit RPC response before committing.

Refactor writeBuildkitdTomlFile to accept a BuildkitdConfig parameter
instead of hardcoding GC policy values. This makes it trivial to switch
from hardcoded defaults to server-provided config when the proto is
updated (Phase 2).

Add runPreCommitHooks dispatcher that executes an ordered list of opaque
shell commands with timeout and failure mode handling. The commit flow
now goes through prepareCommit -> runHooks -> conditionalCommit, with
Phase 1 returning unconditional commit + empty hooks.

Phase 1 (now): hardcoded gc=true, keepDuration=192h, no hooks
Phase 2: server returns BuildkitdConfig in GetStickyDiskResponse
Phase 3: server returns hooks via PrepareCommit RPC

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* chore: remove unused rollup build artifacts

Remove rollup.config.js and rollup devDependencies (@rollup/plugin-node-resolve,
@rollup/plugin-typescript, rollup). The repo switched to ncc for bundling in
commit 2ffcb3d; rollup artifacts were never cleaned up. The dist/main.bundle.mjs
file was already deleted in a prior commit.

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>

Add the required cache-key input to test-action.yml and
step-duration-regression.yml so they work on the release/v2 branch.
Also trigger on push to release/v2 branch.

Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

…) (#113)

* fix: treat RuntimeMaxSec SIGTERM (exit 143) in bbolt check as timeout skip

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* remove bbolt integrity check entirely

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>

… disk (#119)

Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* fix: do not report user input errors to Blacksmith backend

A missing required cache-key input (common for workflows still on the v1
invocation style) was reported to /stickydisks/report-failed as a
STICKYDISK_SETUP failure, polluting platform failure metrics and paging
alerts with what is a user configuration error.

Introduce UserInputError, throw it from our own cache-key validation
(replacing the @actions/core required-input throw), and have
reportBuildPushActionFailure skip reporting any UserInputError. User-facing
behavior is unchanged: the action still warns and falls back to a local
builder (or fails with nofallback), now with a clearer migration message.

dist/ is intentionally not rebuilt here; it is rebuilt as part of the
release process.

Co-authored-by: Codesmith Staging <[email protected]>

* chore: rebuild dist

dist as built by CI from this exact source (commit 04c811d, produced by the since-removed update-dist workflow run with BUF_TOKEN).

Co-authored-by: Codesmith Staging <[email protected]>

---------

Co-authored-by: Codesmith Staging <[email protected]>

… to the local builder when unavailable (#122)

Co-authored-by: Codesmith Staging <[email protected]>

#124)

Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

…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>

…dkitd (release/v2) (#137)

When setup-docker-builder runs more than once in a job, only the first
instance starts buildkitd and mounts /var/lib/buildkit. Later instances
(builderMode=existing) already skipped shutdown but still ran the unmount
path while buildkitd was alive, failing with 'target is busy' and
reporting BUILDER_CLEANUP for a disk they do not own. Exit the post step
early in that case; the teardown telemetry report is still shipped.

Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* post: fstrim the buildkit sticky disk before unmount at commit

Pruned layers keep their RBD extents allocated on the backing store until
the guest discards them. Run a best-effort fstrim on /var/lib/buildkit
before unmount, only when the run is still on track to commit (integrity
check passed, no early deny, no SIGKILL, no failed steps) and only when
the host enabled it: the VM agent returns
GetStickyDiskResponse.fstrim_timeout_secs (fa live config
guest_fstrim_timeout_secs), saved in action state at mount time; 0 means
no trim. Any failure or timeout only logs.

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
(cherry picked from commit 3d2979f)

* setup: read fstrim_timeout_secs from unknown field 8 when the proto package predates it

The bundled GetStickyDiskResponse has no fstrim_timeout_secs yet, and protobuf-es keeps fields it does not know in $unknown (the gRPC transport is binary), so decode field 8 from there when the typed field is absent. Releases built before the field existed therefore honour the host budget once the agent sends it.

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
(cherry picked from commit 56214f0)

* setup: read fstrim_timeout_secs from the regenerated proto package

Bump @buf/blacksmith_vm-agent.bufbuild_es to the FastActions/fa main build
that carries GetStickyDiskResponse.fstrim_timeout_secs (and @bufbuild/protobuf
to its ^2.16.0 peer), read the typed field directly, and drop the unknown
field 8 decoding.

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* post: report the fstrim result in DockerJobLifecycle

trimFilesystem returns outcome (ok/timeout/unsupported/failed/skipped),
duration and the fstrim -v byte count; the post step stores them on the
lifecycle so shipTeardownReport can send them once the proto package
carries the fields (fa: DockerJobLifecycle 28-30).

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* post: pass the host fstrim minimum free-extent size as fstrim -m

GetStickyDiskResponse.fstrim_min_extent_bytes (fa #6823) is saved as action
state next to the timeout budget and, when positive, becomes
`fstrim -m <bytes>` so free extents below the host's threshold are not
discarded. Zero or absent leaves fstrim at its default. Bumps the @buf
vm-agent package to the fa main build that carries field 9.

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* post: report the fstrim result as DockerJobLifecycle fields 28-30

fa #6812 added fstrim_duration_ms, fstrim_outcome (FstrimOutcome enum) and
fstrim_bytes to DockerJobLifecycle; the post step already collected them,
this serializes them. fstrimOutcomeToProto maps the action's outcome
string onto the enum. Bumps the @buf vm-agent package to the fa main build
that carries the 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>

…e/v2) (#142)

Co-authored-by: Codesmith Staging <[email protected]>