J

JUnit report

Outputs & exporters available

Write a JUnit XML report of checks and thresholds for CI.

Install
$ loadr plugin install junit-report
examples/plugins/junit-report.yaml
# 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.