GeezerVison

What's Changed

🚀 Features

• Git Flow context for new launches. allurectl can now send the git context of a run (repository, branch, commit, first-parent commit history and pull request) when it creates a new Allure TestOps launch. The feature is off by default.

  Supported commands: watch, upload, job-run start and launch create. The context is sent only when a new launch is created; uploads to an existing launch (--launch-id / ALLURE_LAUNCH_ID) do not send it.

  Requires Allure TestOps 26.3.1 or later.

Enabling

allurectl watch --git-flow -- ./gradlew test

Automatic detection

Repository, branch, commit and pull request data are read from the CI environment for GitHub Actions, GitLab CI, Azure Pipelines, Jenkins, Bitbucket Pipelines, AWS CodeBuild, Drone and CircleCI, and from the local git repository. When CI does not provide the repository, it is taken from the origin remote, so the feature also works in other CI systems and on a developer machine.

• In a shallow clone, allurectl deepens the history with git fetch --deepen to collect the commit history. It does not change the clone into a partial clone.
• Git commands have a timeout and never wait for credentials.
• On GitHub pull requests, the commit is the pull request head, not the temporary merge commit.
• Tag builds are never reported as branches.
• A pull request without a known source or target branch (for example, a branch build with an open merge request) is reported as a branch.
• Repository and pull request links are built for GitHub, GitLab and Bitbucket.

Fine-tuning with environment variables

These variables take priority over CI detection and the local git repository. Use them when your CI system is not detected or reports wrong values.

Error handling

Git Flow never stops a run. If the git context cannot be collected (no git CLI, no repository, unknown provider), the launch is created without it and a warning is logged. Invalid values of ALLURE_GIT_FLOW and ALLURE_GIT_ANCESTOR_LIMIT are ignored.

To see why git commands fail, set ALLURE_DEBUG=true and run allurectl with --log DEBUG.

What's Changed

🐞 Bug Fixes

• Fixes watch serializing uploads despite set --concurrency

What's Changed

🔬 Improvements

• Version introduces optional parameter that forces the tool to validate the JSON files to be uploaded
  • parameter --validate-json
  • parameter is disabled by default
  • files to be validated before upload
    • -result.json
    • -container.json
    • -globals.json

The introduced parameter allows preventing the upload of files that are not ready for the upload, e.g. for the cases when test is still writing to the result file or file's size is zero due to the integration results creation is not done via tmp file.

What's Changed

Improvements

• Respect and correct processing of Allure TestOps upload quotas in allurectl watch
• Improved the behavior of the tool when processing empty files while watching the result dirs.

What's new

• Add per-file idempotency keys to result uploads.

What's changed

🔬 Improvements

• Proper warning and processing of Allure TestOps errors is added for the working with older Allure TestOps versions that are not capable of processing of global errors and global attachments.

What's Changed

🚀 New Features

• Supported launch-level attachments and errors from Allure globals
• Supported attaching watched command output to Allure TestOps launches as global attachments to launches.

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.