Changelog¶
rampa 0.0.1a2 (2026-05-27)¶
Notes on the upcoming release will go here.
rampa 0.0.1a1 (2026-05-27)¶
rampa 0.0.1a1 ships pluggable output backends, protocol clients for WebSocket and gRPC, distributed execution primitives, a Textual-based TUI dashboard, and a Rust-backed HDR histogram for O(1) metric aggregation. The engine gains mid-run pause/resume, live threshold evaluation with grace-period abort, and graceful signal handling.
What’s new¶
Output backend ecosystem¶
Eight output backends — console, JSON, CSV, InfluxDB, webhook,
Prometheus remote-write, OpenTelemetry OTLP, and GitHub Actions
annotations — plugged in via --output backend=destination. Multiple
backends run simultaneously in a single test. (#4)
WebSocket and gRPC protocol clients¶
worker.ws and worker.grpc lazy properties give scenarios access to
WebSocket sessions and gRPC unary/streaming calls with automatic metric
emission matching k6’s ws_* and grpc_* vocabulary. (#4)
Distributed execution primitives¶
Deterministic work partitioning via ExecutionSegment,
self-contained .rampa archive bundles for shipping tests to remote
workers, and a coordinator/worker wire protocol with JSON and MessagePack
encoding. (#4)
TUI dashboard¶
Textual-based live dashboard showing VU counts, iteration rate, HTTP
timing percentiles, and threshold status. Progressive display hierarchy:
console summary (default), --progress single-line, --tui full
dashboard. (#4)
Rust HDR histogram¶
PyO3-wrapped hdrhistogram crate replaces the Python list-based
TrendSink. Fixed ~20 KB memory and O(1) percentile queries regardless of
sample count, with automatic fallback to the Python implementation when
the extension is unavailable. (#4)
Pause/resume and live thresholds¶
Mid-run pause/resume via RunController, with zero-overhead
wait_if_paused() gate on each iteration. Thresholds evaluate
periodically during the run with configurable grace periods, emitting
LiveThresholdEvent for real-time dashboard updates. (#4)
rampa inspect command¶
Show the fully resolved test configuration — scenarios, thresholds, executor defaults — in text or JSON without running the test. (#4)
CI integration¶
rampa.ci.compare compares two JSON result files and produces
text, markdown, or JSON delta reports. GitHub Actions composite action
runs a test, uploads the result artifact, and generates a step summary
with baseline comparison. (#4)
MCP discovery and control tools¶
discover_scenarios and inspect_config tools let AI agents inspect
test scripts before running. pause_run and resume_run enable mid-run
control from agent workflows. (#4)
unittest integration¶
RampaTestCase mixin adds run_rampa() to any
unittest.TestCase, accepting a worker function and threshold
expressions for teams that don’t use pytest. (#4)
Documentation¶
Auto-generated reference docs for CLI, MCP, and pytest¶
CLI commands, MCP tools and resources, and pytest fixtures now have
auto-generated reference pages with typed parameter tables and safety
badges. The CLI was migrated from Click to argparse to enable
sphinx-autodoc-argparse directives; help output now includes
colorized example blocks. (#3)
Development¶
Build backend switched to maturin¶
Wheels now include the compiled Rust extension. maturin develop --uv
auto-builds during pytest via a conftest.py cold-start hook. (#4)
rampa 0.0.1a0 (2026-05-24)¶
rampa 0.0.1 ships the complete local load-testing engine. A user can write an async Python scenario function, run it from the CLI, and get trustworthy request metrics, checks, thresholds, and a readable summary with correct exit codes.
What’s new¶
Headless engine with typed events¶
The core engine is fully decoupled from CLI presentation. Engine
constructs per-run state and returns a RunController with
wait(), stop(), snapshot(), and events() methods. Frontends
consume the same headless API without reaching into engine internals. (#1)
EventBus for multi-consumer event delivery¶
EventBus broadcasts PhaseEvent, SnapshotEvent,
and ThresholdEvent to any number of concurrent subscribers.
Thread-safe publishing bridges the metric engine thread to the asyncio
event loop via publish_threadsafe(). (#1)
Six executor types¶
All k6-equivalent scheduling models: constant-vus, ramping-vus,
shared-iterations, per-vu-iterations, constant-arrival-rate,
and ramping-arrival-rate. Arrival-rate executors use open-model
scheduling with dropped_iterations accounting. (#1)
Typed metric model¶
Counter, Gauge, Rate, and Trend sink types behind SinkProtocol.
The metric engine runs in a dedicated thread, draining samples from a
queue.SimpleQueue on a 50ms timer. Built-in metrics cover execution,
HTTP timing, checks, VU counts, and data transfer. (#1)
HTTP client with automatic metrics¶
HttpClient wraps aiohttp and auto-emits timing metrics for every
request: http_reqs, http_req_duration, http_req_failed, data
transfer counters, and per-phase timing via aiohttp TraceConfig. (#1)
CLI with run, check, and doctor commands¶
rampa run executes test scripts with --vus, --duration,
--scenario, --out, --event-log, and --quiet options.
rampa check validates scripts without running them.
rampa doctor reports environment diagnostics. (#1)
MCP server¶
rampa-mcp entry point with tools for starting, stopping, and querying
load test runs. Process-local RunRegistry tracks active and
completed runs with metric snapshots and threshold results. (#1)
pytest plugin¶
@pytest.mark.rampa_scenario marker and rampa_result fixture run
scenarios inside pytest tests. Registered via pytest11 entry point. (#1)
Threshold expressions¶
Expressions like p(95)<500 and rate<0.01 evaluate against metric
sinks and determine pass/fail exit codes. (#1)
--event-log JSONL output¶
rampa run --event-log <path> writes a JSONL event stream for
postmortem analysis — every phase transition, metric snapshot, and
threshold result as a JSON line. (#1)
Development¶
Benchmark scripts¶
Benchmark scripts measure scheduler precision, throughput, metric engine ingestion rate, and HTTP overhead. All produce JSON output for CI regression tracking. (#1)