karate-allure-results

Convert Karate's cucumber JSON into Allure 2 result files.

Why

Karate runs under a JUnit runner, and Allure's JUnit adapter sees JUnit tests — not Karate scenarios. If your runner wraps every feature in a single @Test (the usual shape for a parallel Karate suite), Allure reports {total: 1} while your Cucumber and Karate reports show the real scenario counts. One red test, no detail, no history.

Allure 2 ships no cucumber-json reader either — its bundled plugins are junit-xml, xunit-xml, trx, xctest and friends — so Karate's JSON cannot just be dropped into the results directory. It has to be translated. That is all this does.

allure-cucumberjs does not cover this case: it is a runtime formatter for cucumber-js, not a converter for cucumber JSON produced by a JVM runner.

Install

npx karate-allure-results target/karate-reports allure-results

Or add it to the project that needs it:

npm install --save-dev karate-allure-results

Use

karate-allure-results [reportsDir] [outDir]

| Argument | Default | Meaning | | --- | --- | --- | | reportsDir | target/karate-reports | Scanned recursively for features.*.json. Suites that run features concurrently give each one its own subdirectory, which is why the scan recurses. | | outDir | allure-results | Where *-result.json files are written. Created only once there is something to write. |

| Option | Meaning | | --- | --- | | -h, --help | Print usage | | -v, --version | Print the version | | -q, --quiet | Only print on failure |

Exits 1 when no report files were found, so a pipeline step fails loudly instead of publishing an empty Allure report. Exits 2 on a bad argument.

In a Jenkins pipeline, run it after the test stage and before the Allure step:

sh 'node_modules/.bin/karate-allure-results target/karate-reports allure-results'
allure results: [[path: 'allure-results']]

Programmatic use

const { convert } = require('karate-allure-results');

const { written, counts } = convert({
  reportsDir: 'target/karate-reports',
  outDir: 'allure-results',
  onWarn: (msg) => console.warn(msg),
});

console.log(written, counts); // 42 { passed: 40, failed: 1, skipped: 0, broken: 1 }

featuresToResults(features, sourceName, anchorMillis) is also exported if you want the Allure result objects without touching the filesystem.

What it gets right

These are the things that are easy to get wrong, and that this handles deliberately:

• Statuses stay inside Allure's enum. Allure's Status is exactly failed / broken / passed / skipped. A cucumber status outside that set (pending, undefined, an ambiguous step) becomes broken — never a silent pass.
• Scenario Outline rows keep separate identities. historyId folds in the element's source line, so example rows that share a title do not collapse into retries of a single test case and undercount the run. If a producer emits no line, it falls back to exampleIndex, then to an occurrence counter. The id is stable across runs, so Allure history and trends still work.
• A scenario with zero steps is broken, not passed. It did not run; reporting it green defeats the point.
• Background steps fold into the scenario that ran them rather than becoming a phantom test of their own.
• Timestamps are integer milliseconds, and steps are laid out inside their scenario's window instead of at the Unix epoch. Cucumber JSON carries durations but no wall-clock start, so the timeline is anchored at the report file's mtime and scenarios are laid end to end: the durations are accurate, only their absolute position is synthetic.
• An unparseable report file warns and is skipped, rather than taking down the whole conversion.
• Feature and scenario tags both become Allure tag labels.

Requirements

Node.js 18 or newer. No dependencies.

License

MIT