Build1 publisher3 min readPublished
A file-copy Allure adapter for Katalon, and the history IDs that make retries useful
Allure-Katalon Bridge fills a gap Katalon never shipped, installing by copying eight files into a project. The interesting part is stable history IDs, not the installer.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction

What happened
- JUnit, TestNG and Cucumber each have an Allure adapter; Katalon Studio does not.
- The post describes Katalon Studio as one of the most widely used test automation platforms.
- Allure-Katalon Bridge turns any Katalon Studio project into an Allure-reporting project by copying a handful of files into it, with no plugin installation, no OSGi packaging, no command line required, and no changes to existing Test Cases or Test Suites.
- The project is published at github.com/montbaga/allure-katalon-bridge and on npm as allure-katalon-bridge, under the Apache-2.0 license.
- After install, every test suite run produces one Allure result per test case, with status, timing, suite/host/thread labels, and the test framework identified as Katalon Studio.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
A project called Allure-Katalon Bridge has been published on GitHub and npm under Apache-2.0, and it makes a Katalon Studio project emit Allure results by copying a handful of files into it rather than by installing a plugin [3][4]. That matters because JUnit, TestNG and Cucumber all have Allure adapters and Katalon Studio does not, which has left teams standardising on Allure dashboards with one toolchain that reports somewhere else [1].
The author describes Katalon as one of the most widely used test automation platforms, which is why the absence has been a live annoyance rather than an edge case [2]. Note that everything below comes from the project's own announcement, written by its author; none of it is independently verified here.
The delivery mechanism is the least glamorous and most defensible part. According to the announcement, the install drops a Test Listener that Katalon auto-discovers, three Groovy files under Keywords/allure covering the reporting engine, a properties reader with ALLURE_* environment overrides, and an optional keywords library, plus an allure.properties file and a categories.json tuned to Katalon and Selenium exception types [15]. Two jars come along, allure-java-commons and allure-model at 2.35.4, both Apache-2.0 from Qameta Software [16]. That is eight artifacts and no OSGi packaging, no command line requirement, and no edits to existing Test Cases or Test Suites [17][3]. Installation is a double-click installer per OS, a drag-and-drop of the project folder, a bash or PowerShell script, or npx [13]. Re-running install upgrades in place and leaves a customised allure.properties alone unless you pass --force [14].
The output claim worth reading twice is the stable history ID, which the announcement says makes retries and repeat runs appear as trend data rather than unrelated one-off results [8]. Teams that have bolted Allure onto an unsupported runner before know the failure mode: every rerun becomes a new test identity, the flake history flattens, and the trend graph becomes decoration. Around that, each test case produces one Allure result with status, timing, suite, host and thread labels and the framework named as Katalon Studio [5]; non-passed WebUI test cases get a failure screenshot, with screenshots on every case available as a one-line config change [6]; and stack traces attach automatically on failure [7]. The run ends with a self-contained allure-report HTML file with styles, scripts and data inline, so there is no local server and no allure open step [9].
Suite Collection handling is the other practical detail. Member suites combine into a single report named after the Collection instead of one report per suite, and a suite that runs more than once inside a Collection, once per browser for example, gets a separate entry rather than merging [10]. Suites that open a browser carry that browser in the name in the Suites view; pure API suites get no browser label [11]. Step-level detail, epics, severities and JSON attachments are opt-in through CustomKeywords calls from a Test Case script or Cucumber glue [12].
What to watch: the pinned 2.35.4 jars are a maintenance commitment, since Allure's report format moves and a copy-in bridge has no dependency resolver to bump them [16]. Watch whether re-running install reliably carries jar upgrades forward on projects already in the field [14], and whether Katalon responds with first-party support now that the gap has a public workaround [1].