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.
. 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 | |||||
|---|---|---|---|---|---|---|
Purge Enabled | Indicates whether the purge process is enabled. Purge runs every day if enabled. Run time is dependent on when FlexDeploy was started24 hours if enable, beginning with a few minutes after server startup. If you have concerns with running purge at some specific milestone deployment event, you can disable Purge the purge temporarily. | |||||
| Keep Success Count | How many successful project version builds to keep regardless of Retention Days (Operational)
| How many days of execution data to keep in the operational tables. After this data will be moved to Archive tables. Age of data is determined based on original created time. | Retention Days (Artifacts) | How many days of artifacts to keep in the file system. If Keep Counts discussed below cause the version to be active, Artifacts for those will be kept as well.
| ||
| Keep Failed Count | How many failed project version builds to keep regardless of Retention Days (Operational)
| |||||
| Keep Count | How many project versions to keep for each environment/instance regardless of Retention Days (Operational). This helps you keep a specific number of latest deployments so that you can revert back | outto previous versions if desired. | ||||
| Keep | SuccessPipeline Executions by Release Count | How many | successful project version builds to keep regardless of Retention Days (Operational) (Note: this is a global setting and not specific to an environment/instance)||||
Keep Failed Count | How many failed project version builds to keep regardless of Retention Days (Operational) (Note: this is a global setting and not specific to an environment/instance) | |||||
Retention Days (Archive) | pipeline executions to keep per release. | |||||
Retention Days | How many days of execution data to keep in the archive tables. .
| |||||
Retention Days (OperationalArtifacts and Logs). | Retention Days for Logs | How many days | of execution data to keep | in the log tables. This means workflow execution steps detail and plugin logs. These tables take most of amount of space in database, so it is advisable to control this value to reduce space usage. Logs data is now not archived. You can delete all data from ARC_PLUGIN_EXECUTION_LOG and ARC_WORKFLOW_EXECUTION_DATA tables if you want to free up space in your database. |||
| Number of successful pipeline executions to keep | Number of successful of running pipeline executions to keep in operational tables. | |||||
| Number of unsuccessful pipeline executions to keep | Number of aborted, failed , skipped, or out-of-date pipeline executions to keep in operational tablesartifacts and execution logs. Artifacts and Logs are always kept for executions that are not purged due to Keep criteria, hence latest versions will always have artifacts and logs. |
Purge Rules
- Any workflow execution that is the last successful deployment to an environment is automatically excluded from the purge.
- The three four KEEP related parameters override the
DAYSparameter parameters (ie.eg. ifRetention Days (Operational)isis1 day, anything that which was deployed more than 1 day ago AND is one that needs to be kept to satisfy theKEEPparameters will be excluded from the archive/purgeretained). - The
Retention Days (Artifacts)only affects the removal of the artifacts from the file system. There is no archive of artifacts. TheKEEPparameters will again override the artifact retention days. When the 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.
- When artifacts have been purged, a red circle will appear on next to the project version (as shown in figure 17.28) indicating that the artifacts have been purged. This These project version will also can no longer be available to deploy to any environment. To redeploy this version, the version of the source you would need to be retrieved from source code repository (like SVN) in use and taken through the build/deploy cycle again.
- The
Retention Daysare 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.
...
| title | Click to show properties |
|---|
...
Scenario 2: Retain 60 days of execution data and artifacts
...
| title | Click to show properties |
|---|
...
Understanding the purge KEEP parameters
...
| width | 15% |
|---|
Project Deployments:
...
PROD
...
Properties:
...
- perform a new build using the same revision of the source code.
