What's changed in 2.21.1

🐞 Bug Fixes

• Fixed Bitbucket Pipelines CI links

Bitbucket Pipelines CI links

Bitbucket Pipelines auto-detection now produces HTTPS Bitbucket Cloud UI links instead of reusing the internal git HTTP origin. Job and job-run metadata now points to https://bitbucket.org, with run links using the Bitbucket results path (/pipelines/results/), while still allowing ALLURE_CI_ENDPOINT to override the endpoint when needed.

What's changed in 2.21.0

🐞 Bug Fixes

• Avoid .allure startup failures in restricted home directories (see below)
• Prevent job-run env from overwriting CI run URLs (see below)

Avoid .allure startup failures in restricted home directories

allurectl no longer tries to create $HOME/.allure during command startup. Commands such as watch, upload, and --help can now run in containers or CI environments where the detected home directory resolves to / or another unwritable location.

auth login still creates and writes the config file when credentials are saved, but now fails clearly if the configured path cannot be written and only prints the success message after the config is stored. This also refreshes the repository’s Allure agent workflow guide so future test work uses confirmed local capabilities, CI dump/report conventions, and reviewable evidence expectations.

Prevent job-run env from overwriting CI run URLs

allurectl job-run env now exposes the Allure TestOps job-run link as ALLURE_TESTOPS_JOB_RUN_URL instead of ALLURE_JOB_RUN_URL. This keeps ALLURE_JOB_RUN_URL reserved for the external CI run URL, so workflows that export job-run env before running watch no longer send an Allure TestOps job-run page back to TestOps as the CI URL.

This fixes the case where launches created after export $(./allurectl job-run env) showed links to the TestOps job run itself instead of the original CI job-run URL.

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,824 bytes)

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 104857600

Or from config:

upload-rate-window: 1s
upload-max-requests-per-window: 10
upload-max-files-per-window: 500
upload-max-bytes-per-window: 104857600

Set 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 4

concurrency: 4

The 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

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 test

Add 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.

What's Changed

🔬 Improvements

• fix message typos in the stdout outputs
• Gracefully handle SIGTERM in upload and watch (see below)
• Make watch handle Allure TestOps upload outages predictably (see below)

🐞 Bug Fixes

• Add coverage for missing attachments during upload
• Fix of upload retries and split oversized batches (see below)
• Ignore invalid ALLURE_TESTPLAN_PATH in watch (see below)
• Fix watcher skipping valid parallel test results

SIGTERM handling

allurectl upload and allurectl watch now respond cleanly when CI sends SIGTERM. Instead of hanging on long timeouts or being killed abruptly, the client starts a bounded shutdown, performs best-effort watcher/session cleanup, and exits with the conventional 143 signal code.

For watch, the watched command is also terminated gracefully and given a short window to exit before being force-stopped. Normal watch behavior is preserved: when no signal is received, the final exit code still comes from the watched command.

Handling Allure TestOps outages

allurectl watch now separates test execution from Allure TestOps upload recovery. By default, the watched command is allowed to finish while allurectl retries service-side upload failures, then allurectl exits with code 1 if required results still could not be sent.

Teams that require TestOps as the system of record can use --fail-fast to stop the watched command when reporting cannot recover. Teams that treat TestOps reporting as best effort can use --continue-on-error to log unsent results without changing the test command result; the old --silent flag remains as a hidden deprecated alias. Data rejection errors such as too-large uploads are still surfaced instead of being hidden as service outages.

• New --fail-fast flag to stop watched command on unrecoverable TestOps errors
• New --continue-on-error flag to preserve command exit code despite upload errors
• Deprecated --silent alias for backward compatibility
• Context-aware retry with linear backoff (5 attempts, 100-400ms delays)
• Thread-safe upload error handler callback

upload retries and split oversized batches

Upload batching now reacts to server response codes instead of repeating requests that cannot succeed. When TestOps returns Request Entity Too Large for a multi-file batch, allurectl splits it into smaller uploads; a single oversized file fails once and reports the failure. Permanent client errors are no longer retried, while transient 429 and server errors can still complete within a bounded retry budget.

The upload and watch commands now surface watcher/upload failures to callers instead of only logging them. The upload batch size option is also applied to batching, and files larger than the configured batch capacity are rejected before they can stall batching.

• Exponential backoff for upload retries with bounded delays (50ms → 400ms)
• Batch size validation capped at 1 GiB to prevent memory exhaustion
• Thread-safe batch recording with mutex-protected access
• HTTP status-based retry policy distinguishing permanent vs transient failures

Ignore invalid ALLURE_TESTPLAN_PATH in watch

allurectl watch now only passes ALLURE_TESTPLAN_PATH to the watched test command when it points to an existing test plan file. Empty, missing, or directory values are ignored instead of being forwarded to test adapters, which avoids failures in adapters that reject invalid test plan paths.

When ALLURE_TESTPLAN_PATH is explicitly set but invalid, watch prints a warning and does not silently replace it with a generated job-run plan. If the variable is absent, the existing job-run test plan flow still works: allurectl can generate .allure/testplan.json and pass its absolute path to the child command.

Fix watcher skipping valid parallel test results

allurectl now handles result files that are still settling while tests run in parallel without prematurely spending their retry budget or skipping upload. Files that are still being preprocessed or retried remain in the watcher pipeline until they are actually ready, and changed files refresh their observed hash so a later stable check can pass.

This fixes cases where small, valid Allure result files could be retried as “not ready” and then marked failed before upload, causing missing results in Allure TestOps.

What's Changed

🐞 Bug Fixes

• fix/rft: code refactoring to avoid failures of 386 arch binary

What's Changed

⬆️ Dependency Updates

• fixes: go version and oauth2 vulnerabilities CVE-2025-61729

What's Changed in 2.17.1

🐞 Bug Fixes

• Now job-run env will also set tags for the created launch

⬆️ Dependency Updates

• updates dependencies

Bug fixes

• fixed false positive orphan files detection

Improvements

• Added alternative behaviour the home dir mandatory usage,
  • added fallback to tmp dir for the cases when there is no home dir (e.g. when using lambdas)

What's Changed

🔬 Improvements

• We've updated the dependencies to the most recent versions.

What's Changed

🐞 Bug Fixes

• Increase retry delay