How To: Use ReleaseLocks Command and Packager with Cleanup Option

1 ReleaseLocks command
- 1.1 When to use ReleaseLocks Command
- 1.2 Usage
- 1.3 Reference
2 Packager with “cleanup” option
3 Warning
4 Examples

This page discusses two specific features:

ReleaseLocks command (for non-REF environments)
Packager with “cleanup” option (for REF environments only)

ReleaseLocks command

Datical CLI command hammer releaseLocks have been improved as of version 7.2. This command now supports dropping of the DATICAL_SPERRORLOG table for Oracle databases.

(If using runtime credentials, upgrade to version 7.4 or higher to use hammer releaseLocks.)

If a REF database operation is interrupted, the cleanup option is recommended.
If a non-REF database operation is interrupted, the releaseLocks command is recommended.

When to use ReleaseLocks Command

This command can be used at the end of a Deploy operation as long as no other Datical operations are being performed on the database.

Usage

hammer releaseLocks <dbDef>

Reference

CLI Commands - ReleaseLocks

Packager with “cleanup” option

Starting with version 7.3, the hammer deployPackager.groovy was updated to include a cleanup option. This cleanup option can be used when a Packaging operation has been interrupted and the REF database is left in an unknown or partially deployed state. The deployPackager.groovy cleanup option includes a restore using the backup referenced in the deployPackager.properties file.

(If using runtime credentials, upgrade to version 7.4 or higher to use the packager cleanup option.)

When to use Cleanup Option

The deployPackager.groovy cleanup option includes a restore using the backup referenced in the deployPackager.properties file. Because of this restore, the cleanup option should not be used except in cases where the Packaging job was terminated unexpectedly. We recommend that this should be separate automation job that users can run to clean up their REF databases.

Usage

`hammer groovy deployPackager.groovy pipeline=<pipeline_name> scm=true cleanup`

Reference

CLI - Deployment Packager

Warning

Ensure no other Datical jobs are running on the database prior to using the cleanup option or releaseLocks command.
The deployPackager.groovy cleanup option should only be used in conjunction with a clean automation workspace. Any uncommitted changes to the changelog.xml in the abandoned run will be destroyed along with the workspace.

Examples

Setup Manually Triggered Jobs for Release Locks and Cleanup

A best practice recommendation is to setup jobs to allow users to manually trigger the Release Locks command or Cleanup option from the automation platform. Users should only trigger these jobs after guaranteeing that no other jobs are currently running for that project. For Jenkins, the plugin Build Blocker can help ensure jobs do not run simultaneously.

Issue the Release Locks Command after a Failed Deployment

Run the in the catch block of a failed packaging or deployment job:

hammer releaseLocks ${TARGET_DB}

Using the Jenkins Post Stage Aborted Condition

For customers using Jenkins, there is a an aborted condition in the post stage that can be used during Packaging to issue the cleanup option. The code will only be executed when the current Pipeline’s run has an "aborted" status. See more information at https://www.jenkins.io/doc/book/pipeline/syntax/#post.

post {
  aborted {
    dir("${PROJ_DDB}") {
      sh '''
        echo "===== Jenkins Build Manually Aborted ===="
        echo "===== Running Packager Cleanup ===="
        hammer groovy deployPackager.groovy pipeline=${DATICAL_PIPELINE} scm=true cleanup
      '''
    }
  }
}