Allure Maestro

Convert Maestro JUnit output and execution artifacts into Allure result files for local reports and Allure TestOps.

Created and maintained by Aslı Kanpolat.

Current status

The production baseline is implemented:

• JUnit XML parsing without external runtime dependencies;
• Allure result JSON generation;
• stable testCaseId and historyId values;
• explicit allure.id, allureId, allure_id, testCaseId, or test_case_id identity overrides (allure_id primary label plus legacy as_id compatibility label);
• pass/fail/broken/skipped status mapping;
• tags, selected properties, labels, parameters, and links;
• platform and device metadata for Android, iOS, WebView, and Desktop Web;
• shared Maestro logs, current per-flow commands.json/manifest.json bundles, and matching screenshots/videos as attachments;
• opt-in Allure steps from matched commands-*.json metadata, including nested metadata and honest unknown placeholders for inline runFlow.commands;
• explicit step-level screenshot/attachment references when command metadata provides a path;
• validate command for result JSON and attachment references;
• bounded JUnit/artifact discovery and a safe output-cleaning policy;
• security-review advisories for every copied attachment (the converter does not inspect or upload content);
• shard/device/run metadata and history-context parameters;
• safe rejection of oversized result JSON before TestOps upload;
• strict TypeScript source compiled to a Node.js 20+ CLI on Windows, macOS, and Linux.

Step reconstruction is opt-in with --steps. The parser accepts current per-flow commands.json wrappers (command + metadata, including depth, retry/repeat entries, and artifact paths), older commands-*.json files, and JSONL/array variants. It also understands Maestro's SUCCESS, WARNING, ERROR, CANCELED, and STOPPED JUnit status attributes. Step-level attachments are resolved relative to the command bundle before falling back to safe artifact matching; ambiguous or missing paths produce warnings.

Videos are intentionally skipped unless --include-video is supplied. JUnit inputs and artifact discovery are bounded by default; tune --max-junit-bytes, --max-artifact-files, --max-attachment-bytes, and --max-result-bytes for a known workload.

Quick start

Generate the Maestro report and artifacts:

maestro test --format junit --output build/maestro/report.xml flows/

Convert them:

npx allure-maestro convert \
  --junit build/maestro/report.xml \
  --artifacts build/maestro/results \
  --debug-output build/maestro/debug \
  --platform android \
  --app-stack compose \
  --steps \
  --output build/allure-results \
  --clean

Or run the local checkout directly:

node dist/cli.js convert --junit report.xml --output allure-results --clean
node dist/cli.js validate --input allure-results

Generate a local report with the Allure CLI:

allure generate build/allure-results -o build/allure-report
allure open build/allure-report

For Allure Report 3, use the Node CLI syntax: allure generate build/allure-results --output build/allure-report-v3.

For TestOps, keep upload separate and use allurectl with the generated result directory.

For a completed Maestro run, upload the generated results with:

allurectl upload build/allure-results

The converter never uploads by itself and makes no network calls. Its CLI prints security-review advisories for copied attachments; review generated logs, screenshots, and videos for sensitive content before calling allurectl.

For a streaming CI job, run Maestro and the converter inside the same watch command so the result directory is visible to allurectl:

allurectl watch -- sh -c '\
  maestro test --format junit --output build/maestro/report.xml \
    --test-output-dir build/maestro/results flows/ && \
  node dist/cli.js convert \
    --junit build/maestro/report.xml \
    --artifacts build/maestro/results \
    --debug-output build/maestro/debug \
    --platform android --steps \
    --output build/allure-results --clean'

For shard or device-matrix runs, pass --device, --device-id, --shard-index, --shard-total, and --run-id. Device, device ID, OS, browser, and viewport values are included in the history identity by default; use --no-history-context when matrix executions should intentionally share history.

Use --allure-id EXISTING_TESTOPS_ID for a single-test run-level explicit mapping, or --id-property NAME when IDs are carried per test in JUnit/Maestro properties.

The default result JSON limit is 1,900,000 bytes to stay below the current TestOps processing limit. Large logs, screenshots, and videos remain separate attachments; use --max-result-bytes only when the target upload contract is known to allow a larger value.

Automated versioning

Run Actions → Create release → Run workflow on the develop branch. The release workflow uses MCKanpolat/auto-semver-action to calculate the next version, then runs the test/build checks before updating package.json and package-lock.json, creating a release commit, pushing a vX.Y.Z tag, staging the package on npm, and creating a GitHub Release. The default increment is a patch release. Add an exact token such as #minor or #major to a commit message when a larger release is required.

Configure npm Trusted Publishing with the npm stage publish action enabled, or configure the NPM_TOKEN repository secret. Stable versions use the latest dist-tag; prerelease versions use next. Review the staged package in npmjs.com’s Staged Packages tab and approve it with 2FA, or use npm stage approve <stage-id>. The release inputs also allow minor, major, and prerelease increments to be selected explicitly.

Staged publishing requires the package to already exist on npm. Bootstrap the first public version once with a direct publish, then create the matching baseline tag:

npm publish --provenance --access public
git tag -a v0.1.0 -m "Initial release"
git push origin v0.1.0

Supported target matrix

The converter uses one platform-neutral result model for:

• Android Views, Jetpack Compose, React Native, Flutter, and .NET MAUI;
• iOS UIKit, SwiftUI, React Native, Flutter, and .NET MAUI;
• WebView/hybrid web content;
• Desktop Web/Chromium flows.

The platform must be supplied with --platform when it cannot be inferred from the source report. Platform, app-stack, app ID/URL, device, browser, OS version, and viewport metadata can be added with CLI options.

For Maestro Web flows, use a url header in the flow and pass --platform web plus --url to the converter. The included e2e/web-smoke.yaml is a minimal real Chromium smoke flow.

Development

npm test
npm run check

The source is TypeScript and is compiled to dist/ during build, test, check, and packaging. The published CLI ships compiled JavaScript and runs on Node.js 20+ across Windows, macOS, and Linux; TypeScript is only needed for development.

See REQUIREMENTS.md for the full scope, compatibility matrix, acceptance criteria, and delivery plan. See COMPATIBILITY.md for the supported Maestro artifact families and version policy. See examples/ for GitHub Actions, GitLab CI, and Jenkins allurectl integration examples.