Skip to content

0.28.0

Status: Upcoming — not yet released.

Stove 0.28.0 adds continuous JVM and Go profiling to the existing Stove Server. Enable the JVM profiler in the tracing Gradle plugin or configure the native Go wrapper, run your end-to-end tests, and use Drill Down or MCP to investigate sampled CPU cost, allocation pressure, surviving objects, and lock waits. No separate Pyroscope backend or additional deployed service is required.

Continuous JVM profiling

  • Opt-in stoveTracing.profiling configuration attaches Pyroscope Java agent 2.9.2 to selected Gradle test JVMs. CPU sampling is enabled with profiling; allocation, live-allocation, and lock sampling are optional.
  • Collection starts with the dashboard run ID, carries service/instance identity, and flushes the final partial recording on orderly teardown. Profiling can run independently of OTel Java-agent instrumentation.
  • When tracing and profiling are enabled together, the plugin loads the bundled Pyroscope OTel extension 2.1.4 for local root span correlation. profiling.traceCorrelation=false opts out; Stove retains startup, identity, final flush, and shutdown ownership. Downstream builds need no extra repository or direct GitHub access.
  • Profiles upload directly to Stove Server over HTTP or HTTPS using Pyroscope Java's JFR multipart contract. profiling.serverUrl is configured separately from dashboard event ingestion.
  • Grafana's Apache-2.0 JFR parser is embedded in the Rust server via a Go archive. Recordings use the existing SQLite or PostgreSQL storage, bounded conversion/query budgets, per-run retention, and the normal run purge lifecycle.
  • Shared frame definitions reduce normalized recording size for deep allocation stacks. Upload retries are idempotent.

See Profiling and Drill Down for version-catalog setup, configuration defaults, HTTPS deployment, and resource limits.

The shared-server deployment guide includes both client destinations, CI configuration, gateway routes and prefixes, identity headers, body limits, timeouts/retries, JVM certificate trust, authentication support, and end-to-end verification.

Drill Down

The dashboard adds Drill Down · whole run for performance investigation:

  • CPU and allocation metric cards with readable totals, service selection, and recording-window filtering.
  • Searchable flame graphs, frame details, zoom navigation, and zoom preserved across refreshes.
  • Hottest-method tables ranked by self or inclusive cost, linked to frame highlights.
  • Recording duration, stack record counts, graph coverage, omitted-stack explanations, and sampled-evidence findings.
  • Span details can open Drill Down for a correlated local root span or its trace, with explicit scope, empty-sample guidance, and a return to the entire run.
  • Live refresh, recoverable error and empty states, and layouts for light and dark themes.

Test selection includes whole recordings overlapping that test, including background work. It does not turn sampled profiles into exact per-test attribution.

Profiling evidence for agents

stove_profiles preserves trace/span selectors in follow-up calls. Use a span’s pyroscope.profile.id as span_id; arbitrary child spans and asynchronous thread transitions are not guaranteed to have correlated samples.

stove_profiles exposes run-scoped hotspots, units, sampling settings, recording windows, findings, and source profile IDs. An optional baseline returns evidence from another run of the same application using run-wide service/metric selectors. stove_diagnose includes a run-wide profile summary, even when diagnosing one test.

The bundled Stove skill gains a dedicated profiling guide for configuration, runtime support, HTTPS ingestion, IntelliJ/Gradle execution, and evidence-driven investigation. See MCP profiling evidence.

Runtime support and interpretation

This release supports JVM JFR and native Go pprof profiles. The Gradle plugin profiles the test JVM and applications running inside it. The new go/stove-profiler module wraps pyroscope-go 1.4.3 and starts only when configured. DashboardExternalProfilingOptions supplies the exact run identity to process/container environment mappers, as demonstrated by the Go showcase.

Go CPU, allocation, heap, goroutine, mutex, and block evidence uses the existing Drill Down and MCP queries. Snapshots use the latest recording per instance and metric; interval deltas accumulate. The Go wrapper supports custom authentication headers and HTTP clients, bounded retries, and graceful final flushing without forced GC. See Go developers.

Python, Node.js, Rust, arbitrary cumulative pprof files, Pyroscope Push RPC, and OTLP Profiles are not supported. Separate JVMs and already deployed applications still need custom agent/lifecycle integration.

Allocation profiles indicate memory pressure. Live profiles use the latest recording per instance and report sampled surviving objects, not retained heap or reference paths. Neither high CPU share nor surviving allocations prove a defect, regression, or memory leak. Compare equivalent workloads and corroborate findings with source and heap/GC evidence.

Container shutdown

Container runners now ask Docker to stop the application within gracefulShutdownTimeout before Testcontainers removes it. This lets signal handlers flush profiles and other buffered evidence; previously cleanup could kill the application immediately. Applications that ignore the stop signal are still terminated after the timeout.

Upgrade and operation

  • Align the Stove libraries, tracing plugin, agent plugin package, and Stove Server on 0.28.0 when it is released. Before release, use matching source/pre-release builds containing profiling.
  • Profiling is disabled by default; existing tests do not start collecting unless enabled.
  • IntelliJ users must delegate tests to the configured Gradle Test task for automatic attachment. Native Run Test does not execute the plugin's agent wiring.
  • Shared ingress must forward POST /ingest, preserve X-Stove-* headers, and allow the server's 16 MiB upload limit. HTTPS certificate trust must be configured in the test JVM. Custom authentication headers are not exposed by the JVM profiling DSL yet; the Go wrapper accepts headers and a custom HTTP client.
  • Profile tables are introduced by storage migration V12. Normal server migration handling applies for SQLite and PostgreSQL.
  • Source builds now need Go (the version in profiling-bridge/go.mod) and a C toolchain for the embedded parser. Published server binaries bundle it, including third-party notices; downstream deployments need no Go service.

The repository version and bundled agent plugin manifests are set to 0.28.0. These notes describe upcoming changes and do not announce published artifacts.