Epic Goal

• Enable different pruning policies based on different tag naming patterns to cater for the different lifecycle of images in the same repository or organization.

Why is this important?

• Customers are seeking more flexibility when automating the image lifecycle in busy repositories and organizations. The difference in lifecycle is something that is often reflected in the name of the image tag. For example customers like to only keep the 3 latest images with the string nightly- in their repositories while the general policy for images in the same repository is to be deleted if they are older than 365 days. Images tagged with the string release- may never be deleted.
  With today's auto-pruning policy system that only supports a single policy per repository it is not possible to build such nuanced policies.

Scenarios

1. See acceptance critieria

Acceptance Criteria

• a user should be allowed to enter multiple separate auto-pruning policies for a given organization or repository
• the rules will be processed without particular order and their individual result sets will be processed immediately before moving on to the next rule
  • for example, if an image is already subject for garbage collection by one rule, it cannot be excluded from pruning by another rule
  • as such the logical OR operation is applied conceptually across all policies in a given repo or org
• when processing a repository-level auto-pruning policy set, all auto-pruning policies at the organization level (if any) are executed first
• in the context of a repository a user should see all org-level auto-pruning policies in effect

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. https://issues.redhat.com/browse/PROJQUAY-6140

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>