TürkçeDemo
Menu

Procedure

Govern artifact retention with dry-run, execution, and restore evidence

Apply repository scope, retention, pattern, keep-last, schedule, and archive-on-delete rules in a controlled cleanup flow.

Content statusVerified in sourceDocumentation versionLatest
Smart Kubaba Cleanup Policies screen with scope, retention, keep-last, and schedule values
The Cleanup Policies view is used to verify scope, retention, archive, and schedule rules before a dry run or real execution.

Role and prerequisites

Creating or changing policy requires ManageCleanupPolicy; dry-run or execution requires RunCleanup.

  • A policy must select exactly one scope: all repositories, one repository, or Hosted, Proxy, or Group type.
  • At least one of retentionDays, matchPattern, or keepLastVersions is required; archiveTarget is mandatory when archiving is enabled.
  • Record a test package in advance to verify checksum, usage, and restoration evidence.

Procedure steps

  1. In Cleanup Policies, enter scope, retention, keep-last, match/exclude, schedule, and archive settings; inspect the Affected Repositories preview.
  2. Run the supported dry-run API; after completion, compare candidateCount and target samples with policy expectations. Dry-run must not change storage or metadata.
  3. If scope is correct, confirm Run now. Verify only one PENDING or RUNNING run exists for the policy.
  4. On Tasks > Cleanup & Storage, monitor processed, deleted metadata and storage, archived, and failed counters.
  5. With archiving off, metadata must be DELETED and the active object removed; with archiving on, metadata must be ARCHIVED and the object moved to the archive namespace.
  6. To validate restoration, supply the same package again through the normal publish or upload path; after permission, format, checksum, and overwrite checks, confirm it is ACTIVE with RESTORED evidence.

Success criteria

  • The run reaches COMPLETED and candidateCount, processedCount, and result counters are consistent.
  • Each processed artifact has a cleanup_run_item and a CLEANUP_DELETE or CLEANUP_ARCHIVE lifecycle record.
  • CLEANUP_RUN_STARTED or COMPLETED audit and CLEANUP operation logs are linked by job id.
  • If node loss is tested, the cursor and PostgreSQL lease allow another replica to continue remaining work.

Failure and security boundaries

  • A disabled policy and a second concurrent run are rejected; the one-active-run rule is also enforced by the database.
  • An item failure does not stop the entire run; the failure is recorded and the artifact keeps its prior state.
  • Archived objects are not served from active package endpoints; merely existing in the archive location does not reactivate metadata.
  • Do not start a broad-scope real run until SQL LIKE patterns and keep-last behavior are validated with sample data.