What's changed in 2.20.0
🚀 New Features
- Added configurable upload rate limits (see below)
- Make watch upload error handling explicit and recover closed launches (see below)
- Add CI auto-detection and rerun support guidance for Bamboo, TeamCity, Tekton, and Bitbucket (see below)
Upload rate limits
Adds automatic upload pacing for upload and watch to avoid hitting storage-side throughput limits.
Upload rate limits are controlled by independent per-window budgets:
- window:
1s - requests per window:
20 - files per window:
1000 - bytes per window:
1 GiB(1,073,741,824bytes)
Each budget can be overridden from CLI:
allurectl upload ./allure-results \
--upload-rate-window 1s \
--upload-max-requests-per-window 10 \
--upload-max-files-per-window 500 \
--upload-max-bytes-per-window 104857600Or from config:
upload-rate-window: 1s
upload-max-requests-per-window: 10
upload-max-files-per-window: 500
upload-max-bytes-per-window: 104857600Set a request, file, or byte budget to 0 to disable that specific budget.
Also adds --concurrency for controlling upload workers:
allurectl upload ./allure-results --concurrency 4concurrency: 4The effective default concurrency remains 2. The old --limit/-l option is still supported, but is deprecated in help and prints a warning when used.
Made watch upload error handling explicit and recover closed launches
allurectl watch now classifies Allure TestOps reporting failures into explicit error classes so retry, finalization, --continue-on-error, and --fail-fast behavior is predictable. Transient service problems can still be retried and deferred, while terminal failures such as HTTP 401/403 authorization errors, missing resources, invalid payloads, validation errors, conflicts, and unknown local errors fail instead of being silently ignored.
Closed launches are treated as recoverable resources. Users can opt in to --reopen-closed-launch to reopen a closed launch before creating CI or manual upload sessions, and before finalization retries for files deferred after a closed-launch upload error.
Error policy reference
| Class | Typical causes | Meaning |
|---|---|---|
service_transient
| Network errors, timeouts, canceled requests, missing HTTP status, HTTP 408, HTTP 429, HTTP 5xx | TestOps may recover if retried. |
resource_recoverable
| Closed launch errors such as Launch is closed or closed launch
| The resource is temporarily unusable, but finalization may recover it. |
auth_terminal
| HTTP 401, HTTP 403 | Token, endpoint, project, or permission problem. |
not_found_terminal
| HTTP 404 | Referenced TestOps resource is missing or not visible. |
payload_terminal
| HTTP 413, HTTP 415 | Payload is too large or unsupported. |
validation_terminal
| Other HTTP 4xx responses, such as HTTP 400 or HTTP 422 | TestOps rejected the request as invalid. |
conflict_terminal
| HTTP 409, HTTP 423 | Resource is conflicting or locked. |
unknown
| Local errors without a known TestOps status or transport failure | Retrying cannot be proven safe. |
mixed
| Joined errors from different classes | Combined result is ambiguous or partly terminal. |
| Class | Retry during active upload | Defer to finalization | --continue-on-error
| --fail-fast
|
|---|---|---|---|---|
service_transient
| Yes, up to 5 watch-level attempts | Yes, up to 3 finalization attempts | Suppresses unrecovered reporting error after finalization | Stops the watched command if reporting still fails |
resource_recoverable
| No | Yes, up to 3 finalization attempts | Suppresses unrecovered reporting error after finalization | Stops the watched command on the reporting error |
auth_terminal
| No | No | Not suppressed | Stops or fails immediately |
not_found_terminal
| No | No | Not suppressed | Stops or fails immediately |
payload_terminal
| No | No | Not suppressed | Stops or fails immediately |
validation_terminal
| No | No | Not suppressed | Stops or fails immediately |
conflict_terminal
| No | No | Not suppressed | Stops or fails immediately |
unknown
| No | No | Not suppressed | Stops or fails immediately |
mixed
| No | No | Not suppressed | Stops or fails immediately |
Active upload retries use a linear delay of 100 ms, 200 ms, 300 ms, and 400 ms. Finalization retries use the same delay pattern and only apply to deferrable classes.
By default, watch lets the test command finish, retries deferrable reporting errors during finalization, and fails allurectl if required results still cannot be sent and the watched command itself succeeded.
--continue-on-error preserves the watched command result when TestOps reporting fails, but only for service_transient and resource_recoverable errors. Terminal classes, including HTTP 401 authorization failures, still fail.
--fail-fast treats TestOps reporting as required while tests are running. Any classified reporting error stops or fails the watched command. It cannot be combined with --continue-on-error or the deprecated --silent alias.
--reopen-closed-launch allows watch to reopen a closed TestOps launch before uploading more results. It applies only to closed-launch resource_recoverable errors. Transient reopen failures are classified and retried using the same 3-attempt finalization budget as deferred uploads; authorization, permission, validation, and other terminal reopen failures are not retried or suppressed.
Example:
allurectl watch --reopen-closed-launch --continue-on-error -- ./gradlew test
allurectl watch --fail-fast -- ./gradlew testAdd CI auto-detection and rerun support guidance for Bamboo, TeamCity, Tekton, and Bitbucket
This adds first-class CI detection defaults for Bamboo, TeamCity, and Tekton so uploads create Allure TestOps jobs and job runs with the identities expected by native rerun integrations. Bamboo uploads now use the plan key as the job identity, TeamCity uses the build configuration ID and internal build ID, and Tekton uses namespace/pipeline plus PipelineRun identity. CI endpoints are also populated where possible so newly uploaded jobs can link to configured Allure TestOps integrations.
Bitbucket Pipelines support is tightened for rerun scenarios as well. Uploads now derive the Bitbucket endpoint, keep repository identity stable, prefer the public build number for display, and preserve the CustomName parameter needed by Allure TestOps to start the matching custom pipeline. This fixes the case where Bitbucket-side uploads stored only Branch, making the rerun button unavailable even though TestOps-side runs stored both Branch and CustomName.