Changelog

rampa 0.0.1a2 (2026-05-27)

Notes on the upcoming release will go here.

Documentation

Grok CLI and Antigravity in the MCP install picker

The MCP install docs’ client picker now covers Grok CLI and Antigravity (Google’s agy) alongside Claude, Codex, Gemini, and Cursor. Grok registers through its own grok mcp add verb; Antigravity has no such verb, so its mcpServers snippet is pasted into ~/.gemini/config/mcp_config.json. (#10)

Development

Native-code boundary policy

Architecture decision records now define when and how rampa reaches for native code: a domain-agnostic boundary taxonomy (accelerator, engine, worker) plus load-testing guardrails that keep native speed from changing what a test measures. Charts the course for future Rust work without committing to any yet. (#6)

Self-measurement policy

Three architecture decision records define how rampa tests, benchmarks, and profiles itself: a deterministic end-to-end self-harness run against both the pure-Python and native paths; benchmarking that catches regressions by counting (function calls, allocations, connections) rather than on flaky wall-clock, and reserves latency claims for a named baseline; and one-command, dependency-free profiling that never distorts what a load test measures. Together they make the native-boundary preconditions from ADR 002 and ADR 003 enforceable rather than aspirational. (#7)

Target capabilities (clean-slate vision)

An architecture-decision record now states what rampa is for: a single contract that scales unchanged from a single process to a distributed fleet, honest measurement under load, multi-protocol support behind one interface, and a Python-first core accelerated by Rust only where measurement proves it earns its place. Each capability is anchored to a working example in a production load generator or Python/Rust project, with the technical design handed to a roadmap of follow-up records. (#7)

mcp_swap.py doctor and use-local --env

The dev config-swap helper gains a read-only doctor subcommand that reports the effective MCP-swap environment — which server name each CLI points at (and a mismatch when the repo is registered under a name other than the derived default), un-reverted swaps and orphaned backups accumulating on disk, a state entry whose backup has gone missing, and auth-overriding env vars such as OPENAI_API_KEY. use-local also takes a repeatable --env KEY=VALUE to write env (e.g. a scratch/isolation var) into the server entry without a manual post-edit.

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

ws and 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)