Skip to main content
Version: Deploy 22.1

Automatically Purge Packages According to a User-Defined Policy

You can create a package retention policy (policy.PackageRetentionPolicy) that retains the deployment packages based on the configured regular expression. Deployed packages are never removed by the package retention policy. If a deployed package is part of the packages identified for removal, then it will be skipped, with no impact on other packages.

The package retention policy uses the same sorting method used by Deploy Explorer to select the applicable deployment packages. For more information about Deploy's package version handling, see Deploy package version handling.

Automatically Purge Deployment Packages​

To automatically purge old deployment packages using a policy:

  1. From the side bar, click Configuration.

  2. Click Menu button, then select New > Policy > policy.PackageRetentionPolicy.

  3. In the Name field, type a unique policy name.

  4. In the Regex pattern field, specify a regular expression that matches the packages to which the policy should apply.

  5. From Atleast provide one from the below fields group, enter one or both of the fields as follows:

    • In the Packages to retain field, type the number of deployment packages to retain per application.
    • In the Packages within no of days to retain field, type the number of days to specify the packages you want to retain in the configured application based on the age of the package (from the CI creation date).

    Package Retention Fields

    Note:

    1. The Atleast provide one from the below fields group will be displayed in red font until you enter at least one of the two fields.
    2. By default, automatic policy execution is enabled and will run according to the crontab scheduled defined on the Schedule tab. You can optionally change the crontab schedule or disable execution.

    Tip: You can manually execute a package retention policy by right-clicking it and selecting Execute job now.

Creating Multiple Package Retention Policies​

You can create multiple package retention policies. For example:

ReleasePackagePolicy

  • Regex pattern: ^Applications/.*/\d{1,8}(?:\.\d{1,6})?(?:\.\d{1,6})?(?:-\d+)?$
  • Packages to retain: 30
  • Schedule: 0 0 18 * * *

SnapshotPackagePolicy

  • Regex pattern: ^Applications/.*/\d{1,8}(?:\.\d{1,6})?(?:\.\d{1,6})?(?:-\d+)?-SNAPSHOT$
  • Packages to retain: 10
  • Schedule: 0 0 18 30 * *
important

Package retention policies are executed independently. Therefore, you must define a regular expression that excludes packages covered by other policies. Select the correct regular expression to ensure that a single policy is applied per application.

Example​

An application has the following deployment packages:

  • 1.0
  • 2.0
  • 3.0
  • 3.0-SNAPSHOT
  • 4.0
  • 5.0

Package 1.0 is deployed to the PROD environment and 4.0 is deployed to the DEV environment.

Assuming a package retention policy that retains the last 3 packages and uses the ReleasePackagePolicy regular expression pattern defined above, the packages to be removed will be: 2.0.

From Deploy 10.0 and later, package versions that includes numerals (separated by dots) only will be sorted numerically.

For example, package versions 1.0, 5.90, 5.1.9.0, and 5.100 are sorted numerically as below:

  • 1.0
  • 5.1.9.0
  • 5.90
  • 5.100

Similar sorting method applies to the purge policy and same reflects in the Deploy UI.

Creating Package Retention Policy Based on Number of Days​

The Packages with no of days to retain field allows you to add an additional criteria. You can create a package retention policy that allows you to retain packages based on the age of the packages by specifying the number days in the Packages with no of days to retain field (packageRetentionDays property). The packages older than the specified number of days are purged. You must define at least one of these two fields. You can also define both the fields. Once configured, this field works in addition to the Packages to retain field value. The application packages that satisfy one of these two criteria will be retained.

Example​

An application has the following deployment packages:

  • 1.0—7 days old
  • 2.0—5 days old
  • 3.0—3 days old
  • 5.0—0 days old

Let us assume the regular expression pattern is applied, the packages are retained for different scenarios as described in the following table:

Package Retention PolicyPackages to retain field valuePackages with number of days to retain field valuePackages retained
Retain 4 days old and last 2 versions24Retains 3.0 and 5.0 packages
Retain 2 days old3No value definedRetains 2.0, 3.0, and 5.0 packages
Retain 6 days old or last 1 versionsNo value defined6Retains 2.0, 3.0, and 5.0 packages
Retain 0 days old or last 0 versions00Retains nothing
Retain 0 days old or last 1 version10Retains 5.0

Log Information​

The log information provides details about the package version and the date of creation of the package. Here is a sample log:

=== Running package purge job [my-policy] (No of versions to retain: 1, No of days old to retain: 1, dryRun: True) ===
== Applications/test [packages to remove: 3]
== 3 packages being removed are :
==   1.0 was created at 2021-06-20T11:33:46.692Z which is 7 days old
==   2.0 was created at 2021-06-22T11:33:46.692Z which is 5 days old
==   3.0 was created at 2021-06-24T11:33:46.692Z which is 3 days old
=== Finished package purge job [my-policy] ===