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:

1. the result contains an ALLURE_ID (aka AS_ID) that does not exist in Allure TestOps;
2. the result has no ALLURE_ID (aka AS_ID) and no full-path selector;
3. the Allure Adapter is not official an has no required data on the full path selector
4. ALLURE_ID (aka AS_ID) is set to -1 or unknown to force "Orphaned state"

Fixes:

1. Use only an existing Allure ID from Allure TestOps, not an arbitrary value. For example, create an empty manual test, add its id to automated test code.
2. If you do not use an explicit Allure ID, make sure the result contains a stable full-path identity from an official Allure adapter.
3. Use official integration with Allure Framework and regenerate the results.
4. Update ALLURE_ID (aka AS_ID) to the real AllureID from Allure TestOps (if it's time to do it).

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.