Skip to main content

Deleting old outputs and artifacts

QA-Board deletes the outputs of commits that got no new results for a while, and keeps those of your reference branch and milestones. This page sets how long they're kept, which artifacts are deleted, and how QA-Board recreates them.

What data will not be deleted​

  • Recent outputs (more info below).
  • The outputs and artifacts of commits on the project.reference_branch from qaboard.yaml, or on a commit/tag/branch listed as a project.milestones in qaboard.yaml.
  • The batches saved as milestones in the web app, and their commit's artifacts (to redo or compare their runs). The commit's other batches are deleted like any other.

Files exported from the web app are never deleted: delete them yourself when you don't need them anymore.

caution

A commit's branch is the first one QA-Board saw it on. If you merge rebased branches with fast-forward, commits keep their feature branch, not your reference branch.

Configuring garbage collection​

Data can be erased after a period of time where the commit has no new outputs.

qaboard.yaml
storage:
  garbage:
    after: 1month

after: supports human-readable values like 2weeks, 1year, 3months... A commit is old when it got no new outputs for that long, or, if it never had any, when it was authored that long ago.

caution

Data is deleted when the server runs qaboard_clean (see the server's cron jobs), or when admins run or schedule Delete old results in Admin → Storage (cleaning the storage). It applies to all projects: without storage.garbage.after, outputs are deleted after 1month. Use qaboard_clean --help for the options (e.g. --project). qaboard_clean --dryrun lists what would be deleted, without deleting or changing anything.

To also allow deleting results on the reference branch (the latest commit is kept), set storage.garbage.can_delete_reference_branch: true.

note

The server needs to read the project's git repository to know which commits are milestones: projects it can't clone are skipped, with a warning (see connecting your git host).

Deleting results from the web application​

Logged-in users can also delete results from a commit's page, in the batch's menu (see the user guide):

  • Delete failed runs or Delete all runs of a batch.
  • With the Delete files, keep metadata switch, only the files are deleted, and the runs stay listed (they can be redone later). You can then also give a file pattern, like *.png or **/*.py, to delete only the matching files.
  • Delete multiple batches at once.

Deleted runs stay listed, as deleted, until an admin deletes them for good (cleaning the storage).

Batches that are milestones are protected: their runs can't all be deleted this way (only their files, or their failed runs, can). Deleting all the runs of a commit keeps its milestone batches.

Recovering lost data?​

Deleted files can't be recovered: make your results reproducible instead.

  • Keep your whole environment as code, e.g. a Dockerfile: each commit has everything your code needs to run.
  • Let anyone start your CI again for any commit, so that it builds, saves the artifacts and runs your tests (see recreating artifacts).
  • Or run by hand:
git checkout $hexsha
make
qa save-artifacts
qa batch my-batch

Deleting commit artifacts​

Artifacts are not deleted by default, you have to ask for it:

qaboard.yaml
storage:
  garbage:
    after: 1month
    artifacts:
      delete: true

If you want to keep some artifacts (maybe "small" coverage reports defined as coverage_report: ... in qaboard.yaml's artifacts)

storage:
  garbage:
    after: 1month
    artifacts:
      delete: true
      keep:
      - coverage_report
      # also supports relative artifacts paths, folders and globs, e.g.
      - build/my_binary
      - reports/*.html

Notes:

  • The settings that are used are those in the latest commit of the reference_branch defined in qaboard.yaml
  • If you change those settings, artifacts for already deleted commits don't get deleted.
  • Subprojects of a repository share each commit's artifacts folder. Deleting a subproject's artifacts keeps the files that the other subprojects of the same commit still use (e.g. the root qaboard.yaml, shared binaries): they are deleted with the last subproject.
  • QA-Board remembers when, and by whom, artifacts were deleted. The commit page shows it.

When artifacts disappear without QA-Board knowing​

Artifacts can also be deleted outside of QA-Board: cleanup scripts, quotas, users... Before redoing runs or starting tuning, QA-Board checks that the commit's artifacts are usable:

  • the artifacts folder exists,
  • it has the root qaboard.yaml, and the subproject's qaboard.yaml too. Without it, qa would find the parent project's qaboard.yaml, and the runs would be saved in the parent project,
  • the files listed in the artifacts' manifests exist (QA-Board checks up to 500 of them).

Without the folder or a qaboard.yaml, QA-Board never runs from the broken folder: it first brings the artifacts back (see below), and the commit page explains what's missing. Missing files from the manifests only give a warning: your runs may not need them.

When qa save-artifacts saves a commit's artifacts again, QA-Board checks them, and the commit is usable again.

note

Until October 2026, qa save-artifacts didn't save the subprojects' qaboard.yaml (only qatools.yaml). Commits saved by older versions are fixed the first time QA-Board restores their artifacts.

Recreating artifacts​

By default, QA-Board can only restore the artifacts that are in the source code: it checks out the commit and calls qa save-artifacts. Build outputs, like binaries, are not restored.

To rebuild everything, tell QA-Board how to ask your CI to recreate a commit's artifacts. It does it when users redo runs or start tuning on a commit whose artifacts are missing, or click Recreate the artifacts on the commit page:

qaboard.yaml
recreate_artifacts:
  # use one of:
  gitlabCI:
    job_name: build   # retried in the commit's latest pipeline (or started, if it's a manual job)
  jenkins:
    build_url: http://jenkins/job/my-project
    params:
      commit: ${commit.id}
  webhook:
    url: https://ci.example.com/hooks/build
    method: POST      # default
    json:             # or data/params/headers
      commit: ${commit.id}
      branch: ${commit.branch}
  • The CI job must build, then call qa save-artifacts: that's how QA-Board knows the artifacts are back. Until then, redos and tuning are refused with a message, and the commit page links to the build. Requests are not sent again for 2 hours, unless users click Ask again to recreate the artifacts on the commit page.
  • GitlabCI jobs are always those of the project's own repository. Webhooks don't follow redirects.
  • Values can use ${commit.id}, ${commit.branch}, ${commit.branch_slug}, ${commit.artifacts_dir}, ${commit.repo_artifacts_dir}, ${project}, ${subproject}, ${git} (the repository), ${commit.short_id}, ${commit.message}, ${commit.committer}, and who asked: ${user} (their user name, also ${user.name}), ${user.full_name} and ${user.email}. In url and build_url, they are URL-encoded.
  • The server sends the requests: GitlabCI needs GITLAB_ACCESS_TOKEN, and Jenkins needs credentials for its host in JENKINS_AUTH (see the server's environment variables). Webhooks are sent as configured.
  • The settings used are those in the latest qaboard.yaml of the reference_branch, or else the commit's own.
  • The commit page and the tuning form warn about errors in recreate_artifacts, like unknown ${variables}.