How To: Use ReleaseLocks Command and Packager with Cleanup Option
- Former user (Deleted)
- Former user (Deleted)
- Former user (Deleted)
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
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
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
'''
}
}
}
Related content
Copyright © Datical 2012-2020 - Proprietary and Confidential