The following macros are not currently supported in the header:
  • style

Purge Settings

The Purge Settings define the configuration parameters to manage the archiving and purging of FlexDeploy execution data from the database repository, and purging of the artifacts stored in the artifacts repository.




Purge Settings







PURGE_ENABLED

Indicates whether the purge process is enabled

RETENTION_DAYS

How many days of execution data to keep in the operational tables

RETENTION_DAYS_OPERATIONAL

How many days of artifacts to keep in the file system

KEEP_COUNT

How many project versions to keep for each environment/instance regardless of RETENTION_DAYS

KEEP_SUCCESS

How many successful project version builds to keep regardless of RETENTION_DAYS (Note: this is a global setting and not specific to an environment/instance)

KEEP_FAILED

How many failed project version builds to keep regardless of RETENTION_DAYS (Note: this is a global setting and not specific to an environment/instance)

ARCHIVE_RETENTION_DAYS

How many days of execution data to keep in the archive tables


Purging Rules

  • Any workflow execution that is the last successful deployment to an environment is automatically excluded from the purge.
  • The three KEEP related parameters override the DAYS parameter (i.e. if RETENTION_DAYS is 1 day, anything that was deployed more than 1 day ago AND is one that needs to be kept to satisfy the KEEP parameters will be excluded from the archive/purge).
  • The RETENTION_DAYS_OPERATIONAL only affects the removal of the artifacts from the file system. There is no archive of artifacts. The KEEP parameters will again override the artifact retention days. When the artifacts have been purged, a red circle will appear on the project version (as shown in figure 17.28) indicating that the artifacts have been purged. This project version will also no longer be available to deploy to any environment. To redeploy this version, the version of the source would need to be retrieved from source code repository (like SVN) in use and taken through the build/deploy cycle again.
  • The retention days is based on the first date it finds in this sequence: End time of the workflow execution, start time of the workflow execution, created time of the workflow execution, requested start time of the workflow request, or the created time of the workflow request.




Examples of configuring the purge


Scenario 1: Retain the last 3 successful builds in each environment/instance and keep the last 12 successful builds and last 2 failed builds overall. Artifacts will be purged from the file system after 15 days and execution data will be archived after 30 days. Data will remain in the archive for 365 days.


SETTINGS:
RETENTION_DAYS 30
RETENTION_DAYS_OPERATIONAL 15
KEEP_COUNT 3
KEEP_SUCCESS 12
KEEP_FAILED 2
ARCHIVE_RETENTION_DAYS 365


Scenario 2: Retain 60 days of execution data and artifacts

.
SETTINGS:
RETENTION_DAYS 60
RETENTION_DAYS_OPERATIONAL 60
KEEP_COUNT 2
KEEP_SUCCESS 2
KEEP_FAILED 1
ARCHIVE_RETENTION_DAYS 60


Understanding the purge KEEP parameters


Environment:             DEV                 QA                   PROD

Project versions        v9 (failed)

     v10                  v10                  v10

                                    v11                  v11                  v11

                                    v12                  v12                  v12

                                    v13                  v13

                                    v14                  v14

                                    v15                  v15

                                    v16

                                    v17    

                                    v18(failed)

                                    v19


SETTINGS:                                                                                                     These versions are retained

                                                                                                                        due to setting of parameter:

            KEEP_COUNT                                                2                                 v11, v12, v14, v15, v17, v19

            KEEP_SUCCESS                                           4                               v15, v16, v17, v19

            KEEP_FAILED                                                1                                  v18

            DEPLOYED TO AN ENVIRNOMENT             AUTOMATIC              v12, v15, v19


In this example, the only project versions that will be checked against the RETENTION_DAYS would be v9, v10, and v13. Those three versions will only be purged/archived in they are older than the retention days parameters.

The following macros are not currently supported in the footer:
  • style