Appearance
Import test reports
Sulu ingests standard test report formats server-side — no per-framework adapter library needed. Enable the reporter your framework already has (Allure or JUnit XML), then get the results into Sulu in any of three ways.
Supported formats
| Format | What you get |
|---|---|
| allure-results directory | Full fidelity: steps, parameters, attachments (screenshots open right in the launch), fixtures, retry collapse |
| JUnit XML | The floor that every CI tool speaks: status, duration, error message, console output |
| ZIP of either | Same parsing, one file |
Three ways in
- Web UI — on the Launches page click Import and drag the results folder (or a ZIP) into the dialog. Best for one-off uploads and trying Sulu out.
suluctl— a zero-dependency CLI for CI and local runs:suluctl upload --results ./allure-results. See suluctl and the per-framework quickstarts in this section.- REST API — three endpoints (
create → files → finish) if you'd rather script it yourself; see the REST API reference.
What you need
- API token — in Sulu open Profile → API keys and generate one (shown once).
- Project ID — the numeric id of the destination project. On the project's Jobs page click Reporting setup: the snippets there are pre-filled with your current project's id (and backend URL).
How files are tracked
Every uploaded file gets a per-file ledger status: PARSED, DUPLICATE (safe re-upload), FAILED (with a reason code), UNLINKED (an attachment no result referenced — a warning, not an error), or IGNORED (unknown file types). The Web dialog and suluctl both show this table, so a partially-bad upload never silently drops data.
Identity across runs
Results are matched to test cases by fullName (Allure) or classname.name (JUnit). Re-running and re-uploading is idempotent: retries of the same test within one launch collapse to the newest attempt. Renaming a test creates a new test case — same trade-off as every report-based tool.