J
JUnit report
Outputs & exporters availableWrite a JUnit XML report of checks and thresholds for CI.
$ loadr plugin install junit-report
# Write a JUnit XML report of the run's checks and thresholds, driven by the
# `loadr-plugin-junit-report` native OUTPUT plugin.
#
# An output plugin follows the same start / on_snapshot / finish lifecycle as
# the built-in exporters: loadr calls `start(config)` once before the run, hands
# the plugin a metric snapshot roughly once a second, then `finish(summary)` at
# the end. This plugin does nothing mid-run — it renders the whole report only
# in `finish`, so `junit.xml` appears complete-and-valid or not at all, never
# half-written.
#
# Every `check` and every `threshold` becomes one `<testcase>` under a single
# `<testsuite>`: a passing one is an empty (green) testcase; a failing one
# carries a `<failure>` naming what broke. The run's `run_id` rides along as a
# property. CI systems (GitHub Actions, GitLab, Jenkins, CircleCI, Azure
# Pipelines, ...) ingest the file straight into their native test panel.
#
# The transport is pure Rust file writing — no external test-reporter binary and
# no XSLT — so nothing beyond a writable path is required.
#
# Build + install the plugin, then run:
# cargo build -p loadr-plugin-junit-report --release
# mkdir -p dist && cp plugins/loadr-plugin-junit-report/plugin.toml dist/ \
# && cp target/release/libloadr_plugin_junit_report.so dist/
# loadr plugin install dist
# loadr run examples/plugins/junit-report.yaml
#
# Note: loadr also ships a built-in `--junit <path>` flag that covers the common
# case; reach for this plugin when you want the report emitted through the
# output-plugin pipeline alongside other `outputs:` entries.
name: checkout-load
description: Emit a JUnit report of checks and thresholds through the output-plugin pipeline
defaults:
http:
base_url: https://api.example.com
scenarios:
main:
executor: constant-vus
vus: 50
duration: 10m
flow:
- request: { name: list, url: /items }
- request:
name: checkout
url: /checkout
method: POST
checks:
- { type: status, equals: 200 }
- { type: body_contains, value: order_id }
outputs:
# Resolve `junit-report` by name from the plugins dir (after
# `loadr plugin install`). To run straight from a build tree instead, set:
# path: target/release/libloadr_plugin_junit_report.so
- type: plugin
name: junit-report
config:
# Where the report is written. Created (and truncated) in `start`; the
# buffered `<testsuite>` is flushed to it in `finish`. An empty `path`
# fails `start`. `${env.…}` resolves before the config reaches the plugin,
# so a per-branch filename can flow in from the environment.
path: junit.xml
thresholds:
http_req_duration: [ "p(95)<500ms" ]
http_req_failed: [ "rate<0.01" ]
A real run: install from the signed index, then watch the plugin work.
A runtime plugin, never in the binary
Installing pulls a per-platform driver from the signed index, verifies its SHA-256 and checks its ABI before it ever loads. Remove it any time with loadr plugin remove junit-report.