TestOps logo
Try TestOps

Moving reports to Allure TestOps

Automated tests already run, but their results live in CI artifacts, local reports, or a separate report portal. This page describes how to route those results to TestOps so launches, history, analytics, and test cases stay current.

For a guided first upload, start with Continue from Allure Report or Connect Automation to TestOps.

Group reports into projects

Before uploading results, decide which reports should share the same TestOps project.

Use one project for launches, test cases, dashboards, integrations, and access rules that belong to the same working group. That can mean one project per product, service, subsystem, team, or product area.

Keep reports in separate projects when different teams own them, review them independently, or need separate access rules and dashboards.

For the project boundary model, see Projects and collaboration.

Group test runs into launches

Decide which test runs should become one launch.

Use the same launch when results belong to the same delivery scope and should be reviewed together. Keep separate launches when the runs are unrelated, belong to different release decisions, or will be closed independently.

If manual and automated evidence should be reviewed together, use Create combined launches.

Choose the input format

Start with the format your test run already produces.

The best fit is Allure Report result data: *-result.json, *-container.json, and attachments. TestOps also accepts other common result formats, including JUnit XML, Cucumber JSON, xUnit XML, and several legacy formats.

Check the full list in Supported file formats.

If your framework does not have a native Allure adapter, use Send results from an unsupported technology.

Verify one run locally

Before changing CI, run one test command through allurectl watch. This validates the same uploader you will use in the pipeline.

Download the binary for your operating system from Command-line tool - allurectl.

Use the TestOps base URL, a TestOps API token, and the numeric project ID as allurectl environment variables. For token creation and variable details, see Command-line tool - allurectl.

ALLURE_ENDPOINT=<TestOps URL> \
ALLURE_TOKEN=<API token> \
ALLURE_PROJECT_ID=<project ID> \
allurectl watch -- <test command>

Open the created launch in TestOps and review the streamed results. Close the launch when you are ready for TestOps to create or update automated test cases from those results.

Add allurectl to CI

For repeatable result delivery, use allurectl in the pipeline that runs the tests.

For most CI jobs, prefer watch because it runs the test command and streams result files as they appear:

ALLURE_ENDPOINT=<TestOps URL> \
ALLURE_TOKEN=<API token> \
ALLURE_PROJECT_ID=<project ID> \
allurectl watch -- <test command>

For the full command reference, see Command-line tool - allurectl.

After pipeline reporting works, configure the CI integration so TestOps can connect each launch to its source run.

Use the CI-specific integration page for your system:

The setup differs by CI provider, but the end result is the same: uploads arrive with the project, launch, job, and pipeline context needed for review.

Check what metadata moves

After uploads are stable, check whether the launch and generated test cases contain the metadata your team needs for filtering, ownership, history, and analytics.

Start with the metadata that already comes from the result files: tags, links, issues, custom fields, environments, members, layers, and any other labels your adapters or reporters provide. Launch-level and test-case-level metadata may appear in different places, so verify it where the team will use it.

If your team needs additional labels interpreted by TestOps, review Tags, labels, layers, and custom fields.

Next steps

© Qameta Software Inc. All rights reserved.