Automated test results upload

• Run automated tests
• allurectl
• Test keys and Allure IDs

Results are marked as orphaned

Orphaned results appear when TestOps cannot match an uploaded result to an existing test case. Common causes:

• the result contains an ALLURE_ID that does not exist in TestOps;
• the result has no ALLURE_ID and no stable full-path selector;
• the Allure adapter version is too old to emit the required metadata.

Fix:

1. Use only an existing Allure ID from TestOps, not an arbitrary value.
2. If you do not use an explicit Allure ID, make sure the result contains a stable full-path identity from a supported Allure adapter.
3. Update the Allure adapter and regenerate the results.

See: Test keys and Allure IDs

Refactoring created duplicate automated test cases

Renaming packages, classes, or methods changes the identity TestOps uses to match results to test cases. Without an explicit Allure ID, each rename creates a new test case.

Fix:

1. Assign explicit Allure IDs to tests before renaming or restructuring them.
2. Treat parameter-set changes as identity changes unless you stabilize the test with an Allure ID.

See: Test keys and Allure IDs

A rerun stays In progress and later becomes Unknown

The incoming result did not match the expected retry context. Common causes:

• parameter values changed between the original run and the rerun;
• mapped environment values changed;
• the rerun happened in a different job or pipeline context.

Fix:

1. Rerun from the same job and pipeline context when you expect a retry.
2. Move dynamic values out of mapped environments and parameters when they do not define a true execution context.
3. If your framework supports excluded parameters, use that for values that should not affect retry matching.

See: Launch environments, Jobs

Selective execution runs all tests instead of the selected ones

The full chain must be compatible: TestOps triggers the job in two-way mode, the runtime receives ALLURE_TESTPLAN_PATH, the Allure adapter reads testplan.json, and no build tool filter overrides the TestOps plan.

Fix:

1. Confirm the job has a Build Server configured and is enabled for running tests from TestOps.
2. Refresh the job after CI-side changes.
3. Remove extra CLI or framework filters that override the TestOps test plan.

See: Jobs, allurectl

Launch is empty or some files are skipped

Common causes:

• the uploader points to the wrong results directory;
• files were already present before the uploader started watching the directory.

Fix:

1. Verify the path contains the expected result files.
2. If files are copied into place before the uploader starts, use allurectl upload instead of watch mode.
3. For plugin-based uploads, set indexExistingFiles: true when files already exist before the agent starts.
4. Enable debug logging in allurectl with --log debug to see the full HTTP exchange with the TestOps API. See Enable debug logging.
5. Check application-side logs for upload errors. On self-hosted deployments, your administrator can review the logs directly. On Cloud, contact support and provide the job and project details.

See: allurectl troubleshooting

Uploads fail due to file size limits

A single *-result.json file larger than 2,000,000 bytes will not be processed as a test result. Large upload bodies can also be blocked by reverse-proxy limits before TestOps processes them.

Fix:

1. Move oversized textual payloads from result files to attachments.
2. On self-hosted deployments, review reverse-proxy body-size and timeout settings.

See: Network and HTTPS, Cloud limits and quotas

A skipped or setup-failed test creates a duplicate test case

In some Allure adapter versions, the Allure ID label is written late in the execution lifecycle. If the test is skipped or fails during setup before the metadata is emitted, the result arrives without the Allure ID and creates a new test case.

Fix:

1. Keep the Allure adapter version current.
2. Where your framework supports it, place the Allure ID in metadata that is emitted before the test body starts.