Mockarty CLI

Mockarty CLI is a powerful command-line tool for API mocking, testing, fuzzing, performance testing, and CI/CD integration. It works in standalone mode (free, no server required) and connected mode (with a Mockarty server for full platform features).

Zero dependencies. Single binary. Works offline. 5 report formats.

About URLs in examples: All examples use localhost:5770 as the default Mockarty address. If your instance runs on a remote server, replace localhost:5770 with its actual address (e.g. https://mockarty.company.com or http://192.168.1.50:5770). See Tips & Useful Features for details.

Installation

macOS / Linux

curl -sSL https://mockarty.ru/install.sh | sh

Homebrew

brew install mockarty/tap/mockarty-cli

Direct download

Download the prebuilt binary for your platform from the
releases page, then move it
onto your PATH:

chmod +x mockarty-cli-* && sudo mv mockarty-cli-* /usr/local/bin/mockarty-cli

Docker

docker run --rm mockarty/cli version

Verify the installation:

mockarty-cli version

Quick Start

1. Start a standalone mock server

echo '{"id":"hello","http":{"route":"/hello/:name","httpMethod":"GET"},
  "response":{"statusCode":200,"payload":{"message":"Hello, $.pathParam.name!","uuid":"$.fake.UUID"}}}' > mock.json

mockarty-cli serve -f mock.json --port 8080
curl http://localhost:8080/hello/World
# {"message":"Hello, World!","uuid":"a1b2c3d4-..."}

2. Run an API test collection

mockarty-cli run -f collection.json --reporter cli

3. Create a mock on a connected server

mockarty-cli login --server https://mockarty.company.com --token mk_xxx
mockarty-cli mock create -f mock.json

Configuration

Setting the Server URL

By default mockarty-cli points at a local Mockarty instance (http://localhost:5770). You can target any other server — a self-hosted node or an air-gapped deployment — through any of four mechanisms. Higher rows win.

The legacy MOCKARTY_SERVER_URL env var is still accepted as a synonym for MOCKARTY_SERVER to keep old CI scripts working. If both are set, MOCKARTY_SERVER wins.

See Connect to a Server for a deeper walkthrough.

Authentication

# OAuth (recommended; uses the current server URL — cloud by default)
mockarty-cli auth login

# API token (CI/CD, scripts)
mockarty-cli login --server https://mockarty.company.com --token mk_xxx

# Username/password (interactive)
mockarty-cli login --server https://mockarty.company.com --user admin --password secret

# Name the context explicitly
mockarty-cli login --server https://mockarty.company.com --token mk_xxx --name production

# Check current status
mockarty-cli login --status

Environment variables (override config, ideal for CI/CD):

Config file location: ~/.mockarty/config.json

Contexts

Contexts let you manage multiple server connections (like kubectl contexts):

# View all contexts
mockarty-cli config view

# List contexts as table
mockarty-cli config get-contexts

# Switch context
mockarty-cli config use-context production

# Create/update context manually
mockarty-cli config set-context staging --server https://staging.company.com --token mk_xxx --namespace test

# Delete context
mockarty-cli config delete-context old-server

Commands Reference

Mock Server (serve) – Standalone

Start a local mock server with the full Mockarty resolver engine. No server required.

mockarty-cli serve -f mocks/                              # From directory
mockarty-cli serve -f mock.json --port 9090               # Single file, custom port
mockarty-cli serve --har traffic.har                      # From HAR recording
mockarty-cli serve -f mocks/ --proto protos/ --grpc-port 50051  # With gRPC
mockarty-cli serve -f mocks/ --watch                      # Hot-reload on changes
mockarty-cli serve -f mocks/ --cors=false                 # Disable CORS

Supported protocols: HTTP/REST, gRPC (with --proto), SOAP, MCP

The serve command exposes an SDK-compatible CRUD API at /api/v1/mocks, so Go, Python, and Java SDKs work with both standalone serve and the admin node.

Mock Management (mock) – Connected

Manage mocks on a remote Mockarty server.

mockarty-cli mock create -f mock.json             # Create/update from file
mockarty-cli mock create -f mocks/                # All files in directory
cat mock.json | mockarty-cli mock create -f -     # From stdin

mockarty-cli mock list                            # List all mocks
mockarty-cli mock list -o json                    # JSON output
mockarty-cli mock list -o wide                    # Extended table
mockarty-cli mock list --protocol grpc            # Filter by protocol

mockarty-cli mock get <mock-id>                   # Get mock by ID
mockarty-cli mock delete <mock-id>                # Delete mock
mockarty-cli mock logs <mock-id>                  # View recent invocations

mockarty-cli mock export -d backup/               # Export to directory
mockarty-cli mock import -f backup/               # Import from files

mockarty-cli mock apply -f mocks/                 # Declarative create/update
mockarty-cli mock apply -f mocks/ --prune         # + delete mocks not in files

The apply command works like kubectl apply – it creates new mocks, updates existing ones, and with --prune removes server mocks not present in your local files.

API Testing (run)

Execute API test collections with assertions and variable chaining.

mockarty-cli run -f collection.json               # Mockarty format
mockarty-cli run -f postman-export.json           # Postman v2.1 (auto-detected)
mockarty-cli run --har traffic.har                # From HAR recording
mockarty-cli run -f tests/                        # All collections in directory

Reporters (all 5 can be used simultaneously):

mockarty-cli run -f tests.json \
  --reporter cli \
  --reporter json:results.json \
  --reporter junit:report.xml \
  --reporter allure:allure-results

Exit codes: 0 = every step passed and every requested report was written · 1 = a step failed, a report could not be written, or no step ran at all (a dependsOn typo skips the whole manifest — nothing verified is not a pass) · 2 = the run never started (bad flag, unreadable manifest, or a free-tier cap).

Security Fuzzing (fuzz)

Fuzz API endpoints to find vulnerabilities. Free tier: 1 thread, 2 min max.

mockarty-cli fuzz --target http://api.com --spec openapi.yaml
mockarty-cli fuzz --target http://api.com --har traffic.har --strategy all
mockarty-cli fuzz --target http://api.com --spec openapi.yaml \
  --strategy mutation --duration 5m --threads 4 \
  --out json:findings.json --out junit:fuzz-report.xml

Strategies:

Performance Testing (perf)

Run load tests with JavaScript scripts or HAR files. The local CLI allows up to 500 VU and 2 minutes per run without a server.

mockarty-cli perf run script.js
mockarty-cli perf run script.js --vus 50 --duration 5m
mockarty-cli perf run script.js --rps 200
mockarty-cli perf run --har traffic.har --vus 5 --duration 30s
mockarty-cli perf run script.js --out json:results.json --out html:report.html

Contract Testing (contract)

Validate mocks, verify real services, detect drift, check deploy safety, and manage an API registry.

# Validate mocks against spec (requires connected server)
mockarty-cli contract validate --spec openapi.yaml

# Verify a live service against spec
mockarty-cli contract verify --spec openapi.yaml --target http://api.staging.com
mockarty-cli contract verify --spec openapi.yaml --target http://api.staging.com --timeout 120s

# Detect mock drift — compare mocks against real API responses
mockarty-cli contract drift --target http://api.staging.com

# Check if a service version is safe to deploy
mockarty-cli contract can-i-deploy --participant user-service --version "$GIT_SHA" --to production
mockarty-cli contract can-i-deploy --contracts contract-id-1,contract-id-2

# After a successful deploy, record it so can-i-deploy resolves real versions
mockarty-cli contract record-deployment --service user-service --version "$GIT_SHA" --environment production

# API registry — list published API specifications
mockarty-cli contract registry list

Exit codes: 0 = contract valid / safe to deploy · 1 = violations, drift, or a blocked deploy · 2 = the check never ran (missing flag, unreadable spec, server unreachable). -o json carries the same code as the human-readable output.

Chaos Engineering (chaos) – PRO

Run chaos engineering experiments against Kubernetes clusters. Requires a PRO license and a configured K8s cluster.

Cluster management:

# Add a K8s cluster to CLI config
mockarty-cli chaos cluster add --name staging --kubeconfig ~/.kube/config --context staging-ctx
mockarty-cli chaos cluster add --name prod --kubeconfig ~/.kube/prod.yaml \
  --allowed-namespaces app,test --denied-namespaces kube-system

# List, switch, test, inspect, remove clusters
mockarty-cli chaos cluster list
mockarty-cli chaos cluster use staging
mockarty-cli chaos cluster test
mockarty-cli chaos cluster info
mockarty-cli chaos cluster remove old-cluster

Running experiments:

# Run from flags
mockarty-cli chaos run --type pod_kill --k8s-namespace app --selector app=web --duration 5m
mockarty-cli chaos run --type network_partition --deployment my-svc --k8s-namespace app --duration 2m --auto-rollback

# Run from YAML file
mockarty-cli chaos run -f experiment.yaml

# Run from a preset
mockarty-cli chaos preset list
mockarty-cli chaos preset run --preset chaos-monkey --k8s-namespace app --selector app=web
mockarty-cli chaos preset run --preset network-partition --k8s-namespace app --selector app=api --duration 3m

Experiment lifecycle:

mockarty-cli chaos list                               # List experiments
mockarty-cli chaos list --status active               # Filter by status
mockarty-cli chaos get <experiment-id>                # Get experiment details
mockarty-cli chaos abort <experiment-id>              # Abort active experiment
mockarty-cli chaos report <experiment-id>             # Get JSON report
mockarty-cli chaos report <experiment-id> --format html --output report.html

Operator management (K8s):

mockarty-cli chaos operator install                   # Install chaos operator
mockarty-cli chaos operator install --namespace mockarty-chaos
mockarty-cli chaos operator status                    # Check operator health
mockarty-cli chaos operator uninstall                 # Remove operator

install stops and exits non-zero when a prerequisite (ServiceAccount,
ClusterRole, binding) could not be created — an operator without its RBAC
would start and then fail every experiment, so it is not deployed at all.
status exits non-zero when the operator is missing or not ready, so a CI
step can wait on it. uninstall exits non-zero while any object is still on
the cluster. chaos cluster test only passes when the capability probe
completes too — connecting is the easy half.

Interactive TUI:

mockarty-cli tui chaos                                # Interactive TUI

Built-in presets: chaos-monkey, network-partition, scale-to-zero, resource-pressure, rolling-restart-storm, dns-disruption.

Fault types: pod_kill, pod_kill_random, network_partition, network_delay, network_loss, deployment_restart, scale, node_drain, resource_stress, dns_disruption, io_chaos, time_chaos.

Cluster Management (cluster) – Connected

Manage a Mockarty Kubernetes cluster via the admin node API.

mockarty-cli cluster status                            # Show cluster status
mockarty-cli cluster upgrade --tag 1.3.0               # Upgrade all components
mockarty-cli cluster scale resolver --replicas 5       # Scale a component
mockarty-cli cluster restart runner                    # Rolling restart
mockarty-cli cluster logs <pod-name> --tail 100        # Stream pod logs
mockarty-cli cluster logs <pod-name> --follow          # Follow log output

# Add/remove integrations
mockarty-cli cluster add-runner --name sandbox-runner --namespace sandbox
mockarty-cli cluster add-resolver --name shared-resolver --scope admin --replicas 2
mockarty-cli cluster remove-integration sandbox-runner

Code Generation (generate)

Generate mock definitions from API specifications, HAR recordings, or Postman collections.

# From OpenAPI (via connected server)
mockarty-cli generate openapi spec.yaml -o mocks/
mockarty-cli generate openapi spec.yaml --upload    # Generate and upload to server

# From HAR recording (works locally)
mockarty-cli generate har recording.har -o mocks/

# From Postman collection (works locally)
mockarty-cli generate postman collection.json -o mocks/

Utilities

Health check:

mockarty-cli health                        # Check server health
mockarty-cli health --verbose              # Detailed info (version, uptime, license)
mockarty-cli health --wait --timeout 60s   # Wait until healthy

HTTP matcher rollout:

mockarty-cli matcher status                # Mode, snapshot revision and findings per namespace
mockarty-cli matcher status -o json        # Same report as JSON, for a pipeline

The matcher mode is chosen at startup with MOCKARTY_HTTP_MATCH_MODE (off,
shadow, on), so this command only reports — a cutover and its rollback are one
restart apart. In shadow the findings are the disagreements between the compiled
and the legacy matcher, so a namespace with none has been observed to agree. In
on a finding records a request the compiled index could not answer and that the
legacy matcher served instead, which keeps a degraded cutover visible. Findings do
not change the exit status: they are evidence about a migration, not a server
failure.

Wait for readiness (CI/CD):

mockarty-cli wait                                  # Wait for healthy
mockarty-cli wait --mocks user-api,order-api       # Wait for specific mocks
mockarty-cli wait --mock-count 5                   # Wait for N mocks
mockarty-cli wait --timeout 120s --interval 5s     # Custom timing

Port forwarding:

mockarty-cli tunnel --local 5770 --remote server:5770
mockarty-cli tunnel --local 50051 --remote server:50051   # gRPC

Store management (connected):

mockarty-cli store global get                          # Get all global store values
mockarty-cli store global set <key> <value>            # Set a key-value pair
mockarty-cli store global delete <key>                 # Delete a key
mockarty-cli store chain get <chain-id>                # Get chain store values
mockarty-cli store chain set <chain-id> <key> <value>  # Set a key-value pair in chain
mockarty-cli store chain delete <chain-id> <key>       # Delete a key from chain

Namespace management (connected): (alias: ns)

mockarty-cli namespace current                 # Show current namespace
mockarty-cli namespace use <name>              # Set default namespace
mockarty-cli namespace list                    # List available namespaces
mockarty-cli namespace create <name>           # Create a new namespace
# Short form:
mockarty-cli ns current

Audit log export (admin):

# CSV archive for compliance review
mockarty-cli audit export --format csv --output audit.csv

# Syslog RFC 5424 — one record per line, pipe straight to a SIEM collector
mockarty-cli audit export --format syslog > audit.log

# ArcSight CEF — direct ingestion into SIEM (Splunk/ArcSight/QRadar/MaxPatrol/KUMA/RuSIEM)
mockarty-cli audit export --format cef --output audit.cef

# Filter by user, action, resource, namespace, or time window (ms since epoch)
mockarty-cli audit export --format json --user-id u-42 --action login \
    --from 1712345678000 --to 1712431678000

Token management (PRO):

mockarty-cli token create --name "ci-runner" --expires 90d
mockarty-cli token list
mockarty-cli token delete <token-id>

Interactive TUI:

mockarty-cli tui
mockarty-cli tui --server http://localhost:8080

Navigate with arrow keys, Enter to drill down, Esc to go back, q to quit. Shortcuts: c create, e edit, d delete, n new test, u upload, / search.

Traffic sniffer (PRO):

mockarty-cli sniff --target http://real-api.com --port 9090 -o traffic.har
# Point your app to localhost:9090, Ctrl+C to stop and save HAR

AI Agent chat (PRO):

mockarty-cli agent "create a mock for GET /api/users returning a list"
mockarty-cli agent                  # Interactive chat mode

Review self-learned observations before they can reach future missions:

mockarty-cli agent knowledge review list --state candidate
mockarty-cli agent knowledge review show <id>
mockarty-cli agent knowledge review decide <id> --decision publish \
    --expected-version 1 --reason "Confirmed by mission evidence" \
    --idempotency-key review-<id>-v1

Owners and workspace administrators can decide; ordinary members can inspect.
Use --state published|superseded|expired|deleted to revisit lifecycle history.

If an upgrade reports recoverable chat history created before workspace scoping was introduced, review it explicitly. Listing exposes metadata only; export writes transcript data to a private file and refuses to overwrite it unless --force is supplied. Because the original workspace is unknown, claiming requires both a target namespace and an explicit acknowledgement:

mockarty-cli agent sessions legacy list
mockarty-cli agent sessions legacy export <legacy-session-id> \
    --file legacy-session.json
mockarty-cli agent sessions legacy claim <legacy-session-id> \
    --namespace payments --acknowledge-unknown-origin

Use --cursor for the next metadata page and --after-event-id for the next export page when the response indicates more data. Only the original account can see or recover its quarantined history, and claiming also requires write access to the selected namespace.

Backup/restore (PRO):

mockarty-cli backup create
mockarty-cli backup list
mockarty-cli backup download <id> -o backup.tar.gz

Platform installation (install, update, setup):

# Install platform components
mockarty-cli install mockarty                             # Download latest binary
mockarty-cli install mockarty --mode docker-compose       # Generate docker-compose.yml
mockarty-cli install mockarty --mode sqlite               # SQLite single-binary mode
mockarty-cli install --all                                # Install all components
mockarty-cli install mockarty --version 1.2.3             # Specific version

# Check for updates
mockarty-cli update

# Generate deployment config without downloading binaries
mockarty-cli setup docker-compose
mockarty-cli setup env

License management:

mockarty-cli license                        # Show current license info
mockarty-cli license features               # List all features with availability
mockarty-cli license activate <key>         # Activate a PRO license key

Version and logout:

mockarty-cli version                        # Show CLI version
mockarty-cli logout                         # Clear stored credentials

Shell completions:

mockarty-cli completion bash|zsh|fish|powershell
# Pipe output to your shell's completions directory

CI/CD Integration

GitHub Actions

name: API Tests
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Mockarty CLI
        run: curl -sSL https://mockarty.ru/install.sh | sh

      - name: Start mock server
        run: mockarty-cli serve -f mocks/ --port 8080 &

      - name: Wait for server
        run: mockarty-cli wait --server http://localhost:8080 --timeout 30s

      - name: Run API tests
        run: |
          mockarty-cli run -f tests/ \
            --reporter cli \
            --reporter junit:report.xml

      - name: Security fuzzing
        run: |
          mockarty-cli fuzz --target http://localhost:8080 \
            --spec openapi.yaml \
            --out junit:fuzz-report.xml

      - name: Upload test results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: test-reports
          path: |
            report.xml
            report.html
            fuzz-report.xml

GitLab CI

api-tests:
  image: mockarty/cli:latest
  script:
    - mockarty-cli serve -f mocks/ --port 8080 &
    - mockarty-cli wait --server http://localhost:8080
    - mockarty-cli run -f tests/ --reporter junit:report.xml --reporter allure:allure-results
    - mockarty-cli fuzz --target http://localhost:8080 --spec openapi.yaml --out junit:fuzz-report.xml
  artifacts:
    when: always
    reports:
      junit: [report.xml, fuzz-report.xml]
    paths: [allure-results/]

Exit codes make CI integration straightforward: 0 = pass · 1 = the work ran and failed · 2 = the work never ran (mistyped subcommand, unknown flag, missing server, or a feature your licence does not include). Branch on 2 to tell a broken pipeline step from a red test suite. Full table: CLI command reference.

Running what lives on the server

CI usually does not carry the suite in its own repository — the collection and
the load profile are authored in Mockarty and the pipeline just runs them:

# Run the collection maintained in the UI, by name
mockarty-cli run collection "Smoke"

# Dispatch the saved load profile to the runner fleet and block on the result
mockarty-cli perf run-config "Nightly checkout" --wait

Both accept a UUID or a name. A name that matches two entities is refused with
the candidates listed rather than guessed at — dispatching the wrong suite and
reporting success is worse than stopping.

Export a run back to Allure

mockarty-cli testplan report pulls a finished Test Plan run out of the
server as an Allure ZIP archive — the same artifact the UI’s export
button produces. This is the migrate-away path: your historical data never
gets locked in.

# Run → Allure ZIP, unpack, then render a report:
mockarty-cli testplan report <run-id> --plan <plan-id> --zip ./allure.zip
unzip -q ./allure.zip -d ./allure-results
allure generate ./allure-results -o ./allure-report
allure open ./allure-report

The unpacked directory contains everything Allure needs:

• one <uuid>-result.json per test, with a stable historyId and
  testCaseId so Allure’s trends line up across runs;
• every attachment written to its own <uuid>-attachment.<ext> file and
  referenced from the result JSON;
• categories.json, environment.properties and executor.json.

Other formats — the same command serves the run in whatever shape your
pipeline consumes:

# JUnit XML for Jenkins / GitLab / GitHub Actions:
mockarty-cli testplan report <run-id> --plan <plan-id> --format junit --out ./junit.xml

# Markdown summary to paste into a merge request:
mockarty-cli testplan report <run-id> --plan <plan-id> --format markdown

The reverse direction — mockarty-cli allure upload ./allure-results —
ingests an Allure directory back into Mockarty, so the integration is
two-way.

In CI, these commands report what actually happened. allure upload
fails when the directory holds no *-result.json (the suite reported
nothing), when a referenced result or fixture attachment is missing, or when
a run arrives but a large attachment fails to upload. An interrupted upload
also reports the results it could not send. allure launch close
is usually the last step of a job, so it carries the launch’s real outcome:
it exits non-zero when the launch was archived as failed or never received a
result, including on a repeated close of an older empty launch. An external
launch waits for result uploads before it can finish — use --abort when the
pipeline really was aborted. allure export
fails when it would write an empty directory, because allure generate
cannot build a report from one.

Allure result uploads carry a stable key based on the result UUID and launch.
If a connection breaks or the server returns 5xx after a POST, the CLI
retries the same payload and receives the original case-run ID. Reusing the
key for changed result data returns 409; start a new result attempt with a
new result UUID. Upgrade the Mockarty server before using this retry behavior:
older builds do not recognize the key.

allurectl watch --results ./allure-results -- pytest accepts the original
results-directory flag. Watch keeps a result pending while a referenced
attachment is missing and exits nonzero if it still cannot upload it after
the test command exits. Fixture attachments emitted after a result are added
to that result’s run when the test command finishes. An empty results
directory also exits nonzero.
If the test command exits with a positive nonzero code, allurectl watch
returns that same code to CI.

allurectl watch and mockarty-cli allure watch create or resume a
job-scoped launch by default, pass its ID to the test command, upload results,
and finish the launch after every result and attachment arrives. GitLab job IDs
and Jenkins build tags separate parallel jobs. In a local shell, a private
key file inside the results directory survives an interrupted process; it is
removed after confirmed finish. Set ALLURE_LAUNCH_KEY (or
MOCKARTY_LAUNCH_KEY) to supply your own stable job key. A changed request
with the same key returns 409; use a new key for a new job. If upload is
incomplete, watch keeps the launch open so a retry can finish it.

Pass --no-auto-launch to upload without automatic launch management under
either command spelling. The earlier --auto-launch flag remains accepted.
For an explicitly managed launch, create it first,
pass ALLURE_LAUNCH_ID, run watch --require-launch, then finish or abort it
in your CI cleanup step. --require-launch checks namespace and active state
before tests start; it accepts an explicit launch ID or a job-specific
ALLURE_LAUNCH_FILE, never the shared default cache file.

For a remote GitLab or Jenkins rerun, allure rerun-failed --ci-config <id>
triggers the job with the launch ID. A job that runs tests through
allurectl watch -- <command> fetches its own failed-only testplan from
Mockarty and sets ALLURE_TESTPLAN_PATH for the child command. Give that job
Mockarty endpoint, token and namespace settings. If the job starts the
framework without allurectl watch, copy the file written by --out into
the job and set ALLURE_TESTPLAN_PATH there.

Binary aliases for allurectl / supported testit-cli commands

mockarty-cli detects the binary name it was invoked as and auto-routes
to the matching subcommand. That means a CI pipeline that currently
calls allurectl upload can use the binary alias. The testit-cli alias
routes supported commands, but existing Test IT adapters still send HTTP
requests to Test IT; use the Test IT guide to
prepare result data for Mockarty:

For a JUnit XML directory, testit-cli results import --results ./reports
is an alias of results upload; both use the same Mockarty result importer.
Source run tags/links and the official framework adapter HTTP protocol still
need explicit migration.

# Symlink (Linux / macOS):
ln -s /usr/local/bin/mockarty-cli /usr/local/bin/allurectl
ln -s /usr/local/bin/mockarty-cli /usr/local/bin/testit-cli

# Or rename for a hermetic image:
cp mockarty-cli allurectl

# Or copy and rename in a Dockerfile:
COPY mockarty-cli /usr/local/bin/allurectl

Then point the standard env vars at your Mockarty server and run the
same commands as before:

export ALLURE_ENDPOINT=https://mockarty.company.com
export ALLURE_TOKEN=mk_...
export ALLURE_PROJECT_ID=qa-team

allurectl upload ./allure-results        # invokes 'mockarty-cli allure upload'
allurectl launch create --name "PR-42"   # invokes 'mockarty-cli allure launch create'

The testit subcommand accepts TMS_URL / TMS_PRIVATE_TOKEN /
TMS_PROJECT_ID as connection fallbacks. They must contain Mockarty’s URL,
API token and namespace. A Test IT token or numeric project ID cannot be
reused as Mockarty credentials or namespace.

For a CI job that already writes JUnit XML, keep the Test IT command shape:

export TMS_URL=https://mockarty.company.com
export TMS_PRIVATE_TOKEN='YOUR_MOCKARTY_TOKEN'
export TMS_PROJECT_ID=qa-team
testit-cli testrun create --output ./testrun.id
testit-cli results upload -r ./junit-reports -ti "$(cat ./testrun.id)"
testit-cli testrun complete "$(cat ./testrun.id)"

This JUnit path carries basic results. Test IT framework steps, parameters,
and attachments require a richer adapter or converted JSON with attachment
files; see the Test IT guide.

Aliases recognised (case-insensitive, with optional .exe):

TestIT configuration UUIDs

Results upload can identify the execution configuration with a UUID
(--configuration-id or TMS_CONFIGURATION_ID). The ID is stored on
each case result; ad-hoc run creation does not store a configuration ID.
Commands under the testit configuration subtree let CI
scripts manage the value without the TestIT admin UI. testrun complete
returns a failure if no result reached the launch, including a repeated
completion of an older empty launch:

# Emit a fresh UUID4 and pipe straight to the env var:
export TMS_CONFIGURATION_ID="$(mockarty-cli testit configuration generate)"

# List configuration UUIDs already seen in recent external runs
# of the current namespace (sorted, deduplicated):
mockarty-cli testit configuration list

# JSON output for scripting:
mockarty-cli testit configuration list --format json

list scans case_context.metadata.testit.configurationId across
the namespace’s recent runs and emits the distinct values. generate
is offline — no server call, just a UUID4 — so it works in cold-boot
CI setups before the Mockarty endpoint is configured.

Free vs PRO

PRO is activated by connecting to a licensed Mockarty server or by setting MOCKARTY_LICENSE_KEY.

Output Formats

All commands that display data support the -o flag:

Examples:

mockarty-cli mock list -o json | jq '.[] | .id'
mockarty-cli mock list -o quiet | xargs -I{} mockarty-cli mock delete {}
mockarty-cli mock list -o wide

Set a default via environment: export MOCKARTY_OUTPUT=json

Global Flags

These flags work with all commands:

Troubleshooting

For connection issues, re-run the command with mockarty-cli health --verbose to see the full server response, or set MOCKARTY_OUTPUT=json to get machine-readable output.

Related Documentation

• API Reference
• SDK Guide
• Store Systems
• Contract Testing
• Chaos Engineering

Reporting selected CI jobs

A saved CI job started for selected test cases receives a private
MOCKARTY_CI_CONTEXT. Keep it inside that job; do not print it or add it to
framework environment files. allure upload and allure watch use the frozen
case identities to send only matching results to the existing Mockarty launch.
They report the group outcome after the selected uploads, and report a failed
outcome if results or evidence could not be sent. Missing selected results are
still shown as missing by the server.

In this mode watch writes a local ALLURE_TESTPLAN_PATH for frameworks that
support Allure test selection. It removes the private context from the child
command’s environment. The command must honor the testplan to avoid executing
unselected tests. Selected results wait for the command to finish so setup and
teardown evidence can be included before submission. Large attachments are
uploaded before the result. An ambiguous selected result response is not
submitted again automatically; check the launch before starting a new attempt.

Existing ordinary upload and watch behavior applies when this private context
is absent. The CLI continues to use the configured Mockarty endpoint, token and
namespace; no vendor test management server is needed for these reports.