Katalon Studio has no native Allure adapter. Here's how to get one anyway.

JUnit has an official Allure adapter. TestNG has one. Cucumber has one.
Katalon Studio does not, even though it's one of the most widely used test
automation platforms out there.

Allure-Katalon Bridge fixes that. It turns any Katalon Studio project
into an Allure-reporting project by copying a handful of files into it. No
plugin installation, no OSGi packaging, no command line required, and no
changes to your existing Test Cases or Test Suites.

• GitHub: https://github.com/montbaga/allure-katalon-bridge
• npm: https://www.npmjs.com/package/allure-katalon-bridge
• License: Apache-2.0

What you get, automatically

Once it's installed, 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
• A failure screenshot on any non-passed WebUI test case (screenshot on every test case, pass or fail, is a one-line config change if you want it)
• A stack trace attached automatically on failure
• A stable history ID, so retries and repeat runs show up as trend data in the report instead of unrelated one-off results
• A self-contained allure-report/<Name>_<timestamp>.html file, generated automatically at the end of the run. You double-click it and it opens, same as any other HTML file, because everything (styles, scripts, data) is embedded inline. No local server, no allure open, nothing extra to run.

If you're running a Test Suite Collection, every member suite combines
into a single report instead of one report per suite, and that report is
named after the Collection itself. If the same suite runs more than once
inside a Collection (once per browser, for example), each occurrence gets
its own entry in the report rather than merging into one. A suite that
opens a browser shows exactly which one right in its name in the Suites
view; a suite that never opens one (a pure API test case, say) doesn't
get a browser label at all.

Step-level detail inside a test case is entirely opt-in, from a Test Case
script or Cucumber glue code:

CustomKeywords.'allure.AllureKeywords.step'('Log in as admin', {
    WebUI.setText(findTestObject('Page/input_Username'), 'admin')
    WebUI.click(findTestObject('Page/button_Login'))
})
CustomKeywords.'allure.AllureKeywords.severity'('critical')
CustomKeywords.'allure.AllureKeywords.epic'('Patient Management')
CustomKeywords.'allure.AllureKeywords.attachJson'('Booking payload', responsePayload)

Everything else, the zero-touch part, needs none of that. Steps, epics,
and severities are extras for when you want more detail, not a
requirement to get a working report.

Installing it

Pick whichever fits how you work:

Double-click, the simplest path. Open the folder matching your OS,
double-click the installer, pick your Katalon project folder in the
dialog that opens. Uninstall the same way.

Drag-and-drop: drop your project folder straight onto the installer
file, skips the dialog entirely.

Script, for CI or anyone scripting the setup:

./Linux/install.sh /path/to/your/katalon/project

macOS shares this same script (bash is bash on both), and there's a
Windows PowerShell equivalent too.

npm, works identically on Windows, macOS, and Linux, no need to pick a
platform-specific script at all:

npx allure-katalon-bridge install "/path/to/your/katalon/project"

or install it once and reuse it across projects:

npm install -g allure-katalon-bridge
allure-katalon-bridge install "/path/to/your/katalon/project"

Re-running install on a project you've already set up upgrades it in
place, no side effects. A customized allure.properties is left alone by
default; add --force (or -Force on the PowerShell script) if you want
it overwritten with the shipped default too.

What actually lands in your project

Test Listeners/AllureTestListener.groovy      auto-discovered by Katalon, the only wiring needed
Keywords/allure/AllureReportBridge.groovy     the engine: status mapping, attachments, environment/executor/categories files
Keywords/allure/AllureConfig.groovy           allure.properties reader, with ALLURE_* env var overrides
Keywords/allure/AllureKeywords.groovy         optional: step(), attachText/Json/Html/File/Screenshot, epic/feature/story/severity/label/link/issue/tmsLink/parameter
Include/config/allure/allure.properties       configuration file (results dir, screenshot policy, and more)
Include/config/allure/categories.json         failure categorization tuned to Katalon/Selenium exception types
Drivers/allure-java-commons-2.35.4.jar        Apache-2.0, from Qameta Software
Drivers/allure-model-2.35.4.jar               the only 2 extra jars needed
Drivers/fetch-allure-jars.ps1                 re-downloads those 2 jars from Maven Central if your org won't commit binaries to git
View Allure Report.bat / .command             optional: opens your most recent report for you
view-allure-report.sh                         same, for Linux/CI or manual use

Everything it installs is tracked in .allure-bridge/manifest.txt, so
uninstalling removes exactly what was added and touches nothing else in
your project. allure-results/ (your generated test output) and your
allure.properties are kept by default even after uninstall.

Configuring it

Everything lives in Include/config/allure/allure.properties, and any key
can be overridden per environment with ALLURE_<KEY_IN_UPPER_SNAKE_CASE>
(so allure.results.dir becomes ALLURE_RESULTS_DIR), handy for pointing
different CI environments at different result folders without touching
the file itself.

Key	Default	What it does
allure.enabled	true	Master switch
allure.results.dir	allure-results	Where raw results are written
allure.clean.results.before.run	true	Clears last run's results first, so a report only shows the run it's named after
allure.attach.screenshot.on.failure	true	Screenshot on any non-passed status
allure.attach.screenshot.always	false	Screenshot on every test case, pass or fail
allure.categories.file	Include/config/allure/categories.json	Failure categorization template
allure.auto.generate.report	true	Auto-runs allure generate after every suite
allure.report.dir	allure-report	Where the generated HTML report lands
allure.report.single.file	true	One self-contained .html file; set false for a folder instead, useful for very large suites
allure.commandline.path	auto-detected	Manual override if auto-detection can't find your allure install

CI, out of the box

Ready-to-copy configs ship for Azure Pipelines, GitHub Actions, and
GitLab CI. Copy the one matching your platform, fill in one line with
your Test Suite or Collection path, add your Katalon API key as a secret,
and push.

executor.json auto-detects Jenkins, Azure Pipelines, GitHub Actions,
and GitLab CI from each platform's own standard environment variables, so
your Allure report header links back to the exact build that produced
it, with zero configuration on your end.

One flag worth calling out if you're setting this up yourself:
--config -webui.autoUpdateDrivers=true. Hosted CI agents update their
browsers automatically, and Katalon's bundled WebUI driver can fall
behind that, so without this flag a suite can start failing with
SessionNotCreatedException purely because the agent's browser moved
past what the bundled driver supports. This flag tells Katalon to fetch a
matching driver at run time instead.

Requirements

• Katalon Studio (built against long-stable public APIs, so it isn't pinned to one specific version)
• Windows or macOS to use the double-click installer as-is; Linux works through the install script from a terminal
• The Allure commandline (npm install -g allure-commandline) to auto-generate the HTML report and view it. The bridge auto-detects it across PATH, common install locations, and your login shell; if it still can't find it, one clear warning tells you exactly what to set

Why it's built the way it is

Problem	How it's solved
No hook to drive Allure's lifecycle from Katalon	Katalon's public, documented Test Listener API (@BeforeTestSuite/@BeforeTestCase/@AfterTestCase/@AfterTestSuite)
Allure's Jackson clashes with Katalon's bundled Jackson	Ships only allure-java-commons and allure-model, whose Jackson is shaded internally
Results land in a different folder depending on IDE vs CLI vs CI	Results directory is resolved explicitly against the project root, not the process's working directory
A reporting bug could fail or change the outcome of a real test	Every hook catches its own exceptions and only logs a warning
Can't afford to touch thousands of existing test cases	Fully automatic at the suite/case level; step-level detail is entirely opt-in

Get started

npx allure-katalon-bridge install "/path/to/your/katalon/project"

Reopen the project in Katalon Studio, run a test suite like you always
do, and a finished report is already waiting for you in allure-report/
by the time it's done. No extra click, no extra script.

If you run into a Katalon or CI combination that doesn't work, open an
issue on the repo. Questions or help wiring this into a specific setup
are welcome too.