The Purge Settings define the configuration parameters to manage the purging of FlexDeploy execution data from the database repository, purging of the artifacts stored in the artifacts repository, and purging of backups. These settings should be carefully adjusted to meet your data retention requirements for audit, and at the same time purging data which is no longer required to ensure a high performing system.

Property	Description	Default Value

Property	Description	Default Value
Purge Enabled	Indicates whether the purge process is enabled. Purge runs every 24 hours if enabled, beginning with a few minutes after server startup. If you have concerns with running purge at some specific milestone deployment event, you can disable the purge temporarily.	false
Keep Success Count	How many successful project version builds to keep regardless of Retention Days This is a global setting for each project, and not specific to a target.	2
Keep Failed Count	How many failed project version builds to keep regardless of Retention Days This is a global setting for each project, and not specific to a target.	1
Keep Count	How many successfully-executed project versions to keep for each project/target regardless of Retention Days. This helps you keep a specific number of latest deployments so that you can revert back to previous versions if desired.	2
Keep Pipeline Executions Count	How many pipeline executions to keep per release.	30
Retention Days	How many days to keep project executions. If you would like to retain one year worth of history for deployments, keep this value to 365 or higher and still control space usage by using lower value for `Retention Days Artifacts and Backups`. The executions for the purged project version will no longer appear in the project execution screen at all once retention days are passed if the project version is not kept by the keep counts. All executions of each project version are kept or purged together. Age of data is determined based on creation time.	730
Retention Days (Artifacts, and Backups)	How many days to keep Artifacts and Backups, Execution Logs, and Steps. This should be less than or equal to the `Retention Days` parameter. Artifacts and Backups are always kept for executions that are not purged due to Keep criteria, so those are kept longer than this. Execution Logs and Steps may be purged from the `Retention Days of Logs and Steps` parameter. After this purge happens, the version cannot be deployed anymore, although it is still visible in the execution history. All executions of each project version are kept or purged together. The project will look like this afterwards:	15
Retention Days of Logs and Steps	After this many days, old project Logs and Steps are purged regardless of keep counts. Artifacts and Backups are not purged by this. This setting deletes data regardless of the versions that keep counts are keeping. The versions can still be deployed again, but the step details will be missing. This setting is not per project version, but per workflow execution, so older executions may have no steps, but newer ones would still have them. The execution will look like this afterwards. It is still able to be deployed or rolled back. @Since 8.0.0.7	730

Purge Rules

Any workflow execution that is the last successful deployment to an environment is automatically excluded from the purge, unless the project, environment, or target group is inactive.
The four KEEP related parameters override the DAYS parameters (e.g. if Retention Days is 1 day, anything which was deployed more than 1 day ago is still retained if necessary to satisfy the KEEP parameters).
For project version KEEP related parameters, the sum of Keep Success Count and Keep Failed Count will take priority over the Keep Count if it is higher and visa versa. For example, lets say the system was configured with a Keep Success Count of 1, Keep Failed Count of 2, and a Keep Count of 2. If a project only had 2 successful project versions, then both project versions would be kept as the Keep Count would take priority. On the other hand, if a project had 3 successful and 5 failed project versions, then only 1 successful and 2 failed project versions would be kept to satisfy the Keep Success Count and Keep Failed Count.
The Retention Days are based on the first date found 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
- Created time of the workflow request.
Purged executions will not show up on any reports.
When artifacts have been purged, a red triangle will appear next to the project version indicating that the artifacts have been purged. These project version can no longer be deployed to any environment. To redeploy you would need to perform a new build using the same revision of the source code.