TestOps logo
Try TestOps

Cleanup policies

Each test launch generates a considerable amount of data which includes following artifacts:

  • test scenarios;
  • fixtures (common blocks for tests such as SetUp and TearDown);
  • attachments.

Allure TestOps allows you to configure automatic artifact deletion. This can be useful for successful test runs, which often take up a lot of space without providing useful information, as well as for old failed test results.

Cleanup policies control which artifacts Allure TestOps marks and removes. They do not immediately shrink PostgreSQL table files on disk. See Database maintenance below for VACUUM guidance.

Cleanup rules

Allure TestOps provides two types of cleanup rules:

  • Global rule – applies to all projects within the Allure TestOps instance.
  • Project-specific rule – applies in addition to a specific project and does not override global rules.

For example, if you set up a global rule for the deletion of attachments for passed tests after 24 hours, and in the same time on a project level you specify the deletion of the same artifacts after 25 hours, then these rules will be applied to this very project together — files will be deleted after 24 hours and then after 25 hours.

Cleanup rules apply only to closed launches. Specifically, if you have an automatic launch closure policy, artifacts will only be deleted after the launch is closed. For example, if artifact cleanup is set to 24 hours, but the launch closes automatically 72 hours after opening, artifacts will be deleted after 72 hours when the launch is closed.

Default global cleanup rules

New Allure TestOps instances have a predefined set of global cleanup rules. This applies to all instances of the cloud version of Allure TestOps and to newly deployed instances of the server version of Allure TestOps without any existing projects.

By default, the following data is deleted:

  • attachments in successful test results — after 1 week (168 hours);
  • attachments in failed test results and results with other statuses — after 1 month (720 hours);
  • fixtures and test result scenarios — after 1 month (720 hours) regardless of the test result status.

Create a global cleanup rule

To create a global cleanup rule, you must have administrator permissions for the Allure TestOps instance.

  1. Go to Administration → Cleanup policies.
  2. Click the + Create button.
  3. Select the Target and Test status of the target test from the drop-down lists.
  4. Specify the Clean delay (in hours) parameter. It defines number of hours between a test run and the data cleanup.
  5. Click Submit. You can also Edit or Delete created rules.

Create a cleanup rule for a specific project

Global cleanup rules configured by the administrator may not be enough for your project. In this case, you can configure an additional rule for the current project.

To create a cleanup rule for a project, you must be the owner of the project.

  1. Open your project.
  2. Go to Settings → Cleanup policies. Here you can see the global cleanup rules for your system.
  3. Click the + Create button.
  4. Specify Target, Test status and Clean delay (in hours) in the same way as above.
  5. Click Submit. You can also Edit or Delete created rules.

How the cleanup works

The cleanup has 2 stages:

  1. The collection of files eligible for the deletion.
  2. Slow deletion of the files marked for cleanup.

Collecting files eligible for deletion

Compiling a list of files eligible for deletion is a high load request for the database, that is why this operation is executed at night.

Allure TestOps runs cleanup tasks at different times for different rule types:

  • Global rules are processed starting at 02:00.
  • Project-specific rules are processed starting at 02:30.

The database request searches for the files which creation time matches the cleanup rule and moves such files records to a special database table, so the files become marked for the cleanup.

In some cases, files from the same test result can fall under different cleanup rules and therefore be deleted at different times. For more details, see Setup and TearDown blocks.

Slow deletion of the files marked for cleanup

After the cleanup list is compiled, Allure TestOps starts deleting files in batches from this list:

  1. Every 5 minutes Allure TestOps requests the storage to delete a batch of 1 000 files from the cleanup list.
  2. If storage deletes the file or reports a problem, the records are deleted from the table and such files are considered as deleted.

The number of files deleted every 5 minutes depends on your Allure TestOps instance deployment type. The default value of the batch size is 1 000 files.

Troubleshooting and fine tuning

Managing the cleanup batch size

If your tests generate a large number of files, deleting 1 000 files at a time may not be sufficient. As a result, the cleanup queue in the database will constantly grow, and storage will not be freed. To resolve this, you can increase the cleanup batch size.

How to check

To check the cleanup queue size, run the following SQL query against the testops service database in the morning (09:00), in the middle of the day (around 14:00), and at the end of the day (for example, 19:00):

SELECT COUNT(*) FROM blob_remove_task;

If the cleanup queue size is still greater than zero by the end of the workday, you need to increase the batch size of files deleted every 5 minutes. To do this, modify the ALLURE_SCHEDULER_CLEANER_BLOB_BATCHSIZE parameter in the testops service settings, for example: 

ALLURE_SCHEDULER_CLEANER_BLOB_BATCHSIZE: 2000

If the queue size is several hundreds of thousands or millions of records, then you need to set a very aggressive value for the deletion of the files. This needs to be done during the minimal workload (weekends or night time), otherwise big batch could affect the overall performance of Allure TestOps, as the during the test results processing, Allure TestOps uses the storage very heavily and test results processing and the deletion operations will compete for the storage resources.

The batch size for the files deletion should have reasonable value. Don't increase this parameter violently as it will dramatically degrade the performance of your blob storage and generally performance of Allure TestOps.

When to change ALLURE_SCHEDULER_CLEANER_BLOB_BATCHSIZE value

The ALLURE_SCHEDULER_CLEANER_BLOB_BATCHSIZE parameter should be adjusted only if you have configured all necessary cleanup rules, but the storage size still keeps growing or remains unchanged over time. In other words, if you generate more files than you delete.

SetUp and TearDown blocks

Automated test cases executed using an Allure Report adapter can have SetUp and TearDown methods performed before and after the test itself. Since these methods can have a different result from the main test result (i.e., fail independently), Allure TestOps can apply different cleanup rules to them.

For example, let's assume you have configured two cleanup rules regarding attached files:

  • Delete attachments in successful test results after an hour.
  • Delete attachments in failed test results after 24 hours.

If you upload a test result in which the main part was passed successfully but the TearDown step has failed, both rules above will apply. If the main part has attachments, they will be deleted after an hour. If the TearDown step has attachments, they will be deleted after 24 hours.

Tips and tricks

Manual triggering of cleanup procedures

There are no elements in the Allure TestOps interface to trigger cleanup rules, but you can use API commands to initiate the cleanup process outside of the defined schedule:

  1. Open Allure TestOps API description by adding /swagger-ui.html to your Allure TestOps instance URL.

  2. Go to the cleanup-controller section and select one of the API functions:

    • /cleanup/scheduler/cleaner_schema_global — to trigger the global cleanup rules;
    • /cleanup/scheduler/cleaner_schema_project — to trigger project-specific cleanup rules.

Quick creation of cleanup rules for a project

To quickly create the full set of cleanup rules on a project level, you can use this shell script:

ALLURE_TOKEN=<your Allure TestOps token>
ALLURE_ENDPOINT=<Allure TestOps URL>
ALLURE_PROJECT_ID=<your project ID>

TARGET_ARTEFACT="attachment scenario fixture"
TEST_STATUS="passed failed broken unknown skipped"

DELETE_DELAY=48

for ARTEFACT in $TARGET_ARTEFACT
    do
        for STATUS in $TEST_STATUS
        do 
            echo "Marking ${ARTEFACT} for ${STATUS} tests for deletion after ${DELETE_DELAY} after creation \n"
            curl -X POST "${ALLURE_ENDPOINT}/api/rs/cleanerschema" --header "accept: */*" --header "Content-Type: application/json" --header "Authorization: Api-Token ${ALLURE_TOKEN}" -d "{\"projectId\": ${ALLURE_PROJECT_ID},\"status\": \"${STATUS}\",\"target\": \"${ARTEFACT}\",\"delay\": ${DELETE_DELAY}}"
            echo "\n"
        done
    done

You can also use this script for global cleanup rules creation. To do this, remove \"projectId\": ${ALLURE_PROJECT_ID}, from the cURL request.

Recommendations for cleanup rules

Allure TestOps stores three types of artifacts, in descending order of storage consumption:

  1. Attachments — files attached to test results; typically the largest consumer of storage.
  2. Fixtures — SetUp and TearDown step data.
  3. Scenario files — the smallest artifact type.

For each test result status (passed, failed, broken, unknown, skipped) you need three rules — one per artifact type. Without covering all three types, storage will keep growing even if some rules are in place.

Choosing the retention interval

For passed results: keep 1–2 run cycles worth of artifacts. If your tests run once per 24 hours, a 36-hour retention covers the current and previous run with a buffer.

For failed, broken, and other non-passing results: base the interval on how long your team needs to investigate a failure, then add a buffer. For example, if failures are typically resolved within 5 working days, a 168-hour (7-day) retention is reasonable.

Cleanup runs only on closed launches. If a launch stays open for 72 hours and your cleanup delay is 24 hours, artifacts will not be deleted until the launch is closed. Account for your launch closure policy when setting retention intervals.

SetUp and TearDown artifacts

SetUp and TearDown results are treated as separate entities from the main test result. If a test passes but its TearDown step fails, the passed-result cleanup rule applies to the main test attachments and the failed-result rule applies to the TearDown attachments independently.

Database maintenance

Cleanup policies remove artifacts from storage and their references from the database. They do not remove launch metadata or test result metadata — that data is retained indefinitely. If you need to delete historical launches, use the allure-testops-utils CLI tool. Use it with caution: deleting launches is a heavy database operation that can degrade performance under load.

PostgreSQL VACUUM

Allure TestOps performs frequent insert and delete operations. PostgreSQL marks deleted rows as dead but does not reclaim disk space until a VACUUM runs. Without regular VACUUM, tables bloat and disk usage grows even when artifacts are being deleted.

Diagnose dead rows:

SELECT
    schemaname,
    relname,
    n_live_tup,
    n_dead_tup,
    last_vacuum,
    last_autovacuum,
    last_analyze,
    last_autoanalyze
FROM pg_stat_all_tables
WHERE schemaname = 'public'
ORDER BY n_dead_tup DESC;

n_dead_tup shows rows marked for deletion but not yet reclaimed. If this value is large relative to n_live_tup, run VACUUM.

Option 1 — Autovacuum: check whether autovacuum thresholds are configured to trigger frequently enough for high-churn tables:

SELECT name, setting
FROM pg_settings
WHERE name IN ('autovacuum_analyze_threshold', 'autovacuum_analyze_scale_factor');

Autovacuum triggers when dead rows exceed: autovacuum_analyze_threshold + (autovacuum_analyze_scale_factor × live_rows). For large tables with high deletion rates, the default thresholds may be too high and autovacuum may not run often enough.

Option 2 — Manual VACUUM:

VACUUM <tablename>;

Schedule manual VACUUM runs during low-traffic periods. Consult your database administrator for locking implications and the appropriate frequency for your deployment.

ANALYZE: updates table statistics used by the PostgreSQL query planner. Outdated statistics cause the planner to choose inefficient query plans. Run it after large batch deletions or alongside VACUUM:

ANALYZE <tablename>;

Or combine with VACUUM in one pass:

VACUUM ANALYZE <tablename>;

REINDEX: rebuilds indexes that have become bloated or corrupted over time. High insert/delete churn on tables like blob_remove_task can cause index bloat that slows queries even after VACUUM runs:

REINDEX TABLE <tablename>;

Run REINDEX during a maintenance window — it acquires an exclusive lock on the table for the duration of the rebuild. For large tables, use REINDEX CONCURRENTLY (PostgreSQL 12+) to avoid blocking reads and writes:

REINDEX TABLE CONCURRENTLY <tablename>;
© Qameta Software Inc. All rights reserved.