This guide applies to Liquibase Enterprise version 8.2 and earlier. Liquibase Enterprise 8.3 and later automatically adds a deployPackager.properties file when a new project is created. This works in the CLI, GUI, or a project_creator groovy script.

A project must have a deployPackager.properties file in order for SQL scripts to be packaged for it.

deployPackager.properties Configuration

Before using the Deployment Packager, a deployPackager.properties will need to be created in the top level of your Datical project directory. This property file contains a variety of configuration information used by the Deployment Packager to interact with SCM solutions and to perform database backups and restorations.

Note: there is a sample deployPackager.properties file provided in DaticalDB/repl/scripts.

Properties Prefixes for SQL Code and Datical Project Files

The property prefix indicates the type of files it affects and the location of those files.

sqlScm prefix - SQL code files (in predetermined subdirectories)
ddbScm prefix - Datical project files (in a predetermined hierarchy)

When properties for the project are not specified (ddbScm prefix), the values typically default to the properties for the SQL code (sqlScm prefix)

Pipeline and DbDef Branch Settings

In order for the Deployment Packager to process the appropriate scripts for a specific dbdef or pipeline, the SCM branch name and the ID for the last import processed need to be tracked separately in the deployPackager.properties files. These properties should take the following form:

Branch name:
- {PipelineName}.sqlScmBranch
- {DbDefName}.sqlScmBranch for the branch name
Last
- {PipelineName}.sqlScmLastImportID
- {DbDefName}.sqlScmLastImportID.

Refer to the properties in the bottom section of the file below for an example of the Deployment Pipeline specific properties.

Property List for deployPackager.properties

The following properties can be set in the deployPackager.properties file: (note that these properties are NOT in alphabetical order)

Name	Applies to	Description
databaseBackupRestoreLocation	Backup	Location to use for packager-driven backups of the database. During processing, Deployment Packager makes backups of the database that are normally stored on the database server itself. Depending on your DBMS, the location may need to be specified as directory or a specific file. Oracle - the location will be the database directory object name. MSSQL, and DB2 - the directory is on the server host, so the path expression is OS-specific. ('/' on Linux, '\' on Windows.) Postgres - valid path on the server running hammer packaging DB2 - include a trailing slash Windows hosts - Double the backslashes in the path. The backslash ( \ ) is an escape character in Java properties files, so you must write '\\' to stand for '\'. Example: `C:\\Program Files\\Microsoft SQL Server\\MSSQL14.MyInstance\\DaticalBackups`
db2BackupDir.<referenceDBName>=0	Backup	DB2 Only: Set automatically after the first execution of Deployment Packager. The warning from the first execution of packager on a given database can be ignored.
ddlExcludeList	Compares	SQL code types to exclude from a compare, typically to improve performance. When packaging DDL scripts, Deployment Packager compares the before and after state of the reference database. Use this property to exclude object types from the comparison. Values can be: none (the default) all (stored logic) Comma-separated list of these values: procedure, package, packagebody, function, trigger, view, and non_stored_logic. Excluding non-ddl objects can improve performance, especially with large databases. non_stored_logic is available in 8.3 and later. When non_stored_logic is provided for the ddlExcludeList property this will exclude non stored logic database objects (such as tables, constants, etc) from Snapshot, Diff, and DiffChangelog. The preferred style is to separate by comma only. However, spaces and tabs are trimmed if they are encountered. The values list may be enclosed in double quotes or not. Example ddlExcludeList property setting ddlExcludeList="package,packagebody,procedure,function,trigger,view" ddlExcludeList=package,packagebody,procedure,function,trigger,view
ddbScmBranch	Project files	The SCM branch to use. If not specified, Deployment Packager uses the value from sqlScmBranch.
ddbScmDoCheckout	Project files	If this is not present or is set to `true`, Deployment Packager ensures that the local repository is up to date before packaging. To skip this operation, set to `false`. Git - equivalent to `git pull`
ddbScmLastImportID	Project files	The SCM system ID for the most recently processed SQL code check in. It is automatically updated when the Deployment Packager completes successfully. Note: Do not leave blank. Do not use the most recent check-in. For first time use, use an ID from an earlier check-in. Git - first 8 digits of the hash
ddbScmPath	Project files	Path to the local copy of the SCM repository. If this is not present, Deployment Packager will use the value from sqlScmPath.
ddbScmSystem	Project files	SCM type – one of git May be different than the sqlScmSystem. If not specified, Deployment Packager uses the value from sqlScmSystem.
enableBackupRestore	Backup	When the Packager is run in 'dbdef=' mode, the backup and restore routines can be skipped for certain sensitive environments. The value of this property is a comma separated list of the environments in which the Packager should perform backup and restore tasks. NOTE: Backup and restore tasks are NOT recommended for environments beyond development & test.
ephemeralCopyName	Ephemeral database (MSSQL)	[Optional] Defines a name for a DB copy (has impact on SQL Server Ephemeral copy only). Default name for the ephemeral copy will be source database name with `_eph` postfix. For example, if source name is `ABC_DEV`, the copied database name will be `ABC_DEV_eph`. Property Validation: Copy name should be up to 124 characters long, contain no spaces [ ], slashes [/] and semicolons [;] and cannot begin with a number. Available in Liquibase 8.8 and later.
ephemeralCopyWithData	Ephemeral database (MSSQL)	[Optional] By default Liquibase will copy databases without data. () If you would like to copy both the structure and data, use this boolean property. () There is one exception in that the data from the `DATABASECHANGELOG` table is included in the database copy. Property Validation: true/false Available in Liquibase 8.8 and later.
ephemeralSkipFinalDeploy	Ephemeral database (MSSQL)	[Optional] The default value for this setting is false. Any changes being packaged are deployed to the first database in the pipeline during the Deploy Packager operation. Setting this value to true allows changes to be packaged and changesets to be created and stored in the changelog.xml, but the deployment to the first database in the pipeline does not occur. Property Validation: true/false Available in Liquibase 8.8 and later.
oracleBackupNoCrossSchemaFk		When set to true Cross Schema Foreign Keys will not be included in the backup and older backups containing Foreign Keys will not apply those items during a restore. The backup/restore method will not be affected by this property if this property is absent in the deployPackager.properties file or if the value is false. Available in Liquibase 8.5 and later.
oracleBackupNoGrants		When set to true Grants will not be included in the backup and older backups containing Grants will not apply those items during a restore. The backup/restore method will not be affected by this property if this property is absent in the deployPackager.properties file or if the value is false. Available in Liquibase 8.5 and later.
oracleBackupNoDropSchema		When set to true, the Schema(s) will not be dropped. Instead all objects (such as tables, constraints, views, materialized views, functions, procedures, sequences, packages, triggers, synonyms, and user types) within the Schema(s) will be dropped instead. The backup/restore method will not be affected by this property if this property is absent in the deployPackager.properties file or if the value is false. Available in Liquibase 8.5 and later.
oracleEphemeralCopyName	Ephemeral database (Oracle)	[Optional] Defines a name for an Oracle copy PDB in the event the default name is not desired. Default name for the ephemeral copy will be source PDB name with `_eph` postfix. For example, if source name is `bucket_01`, the copied bucket name will be `bucket_01_eph`. Property Validation: Copy name should be up to 30 characters long, contain no spaces [ ], slashes [/] and semicolons [;] and cannot begin with a number. Available in Liquibase 8.6 and later.
oracleEphemeralCopyWithData	Ephemeral database (Oracle)	[Optional] By default Liquibase will copy databases without data. () If you would like to copy both the structure and data, use this boolean property. () There is one exception in that the data from the `DATABASECHANGELOG` table is included in the database copy. Property Validation: true/false Available in Liquibase 8.6 and later.
oracleEphemeralDatabaseLinkName	Ephemeral database (Oracle)	[Optional] Defines a name for a database link which is used with PackageMethod `BackupRestoreOracleEphemeralExternalPdb`. Default link name will be `liquibase_db_link`. Property Validation: Database link name should up to 128 characters long, contain no spaces [ ], slashes [/] and semicolons [;] and cannot begin with a number. Available in Liquibase 8.6 and later.
oracleEphemeralSkipFinalDeploy	Ephemeral database (Oracle)	[Optional] The default value for this setting is false. Any changes being packaged are deployed to the first database in the pipeline during the Deploy Packager operation. Setting this value to true allows changes to be packaged and changesets to be created and stored in the changelog.xml, but the deployment to the first database in the pipeline does not occur. Property Validation: true/false Available in Liquibase 8.6 and later.
oracleEphemeralSourceName	Ephemeral database (Oracle)	[Optional] Defines a source name for an Oracle source PDB in the event Liquibase has not been granted the necessary permissions to query for this name. Necessary permissions are included below. If these grants are not present, oracleEphemeralSourceName will be required. Multi-schema projects: `GRANT SELECT ANY DICTIONARY TO DATICAL_ROLE;` Single schema projects Liquibase requires either: `GRANT SELECT ANY DICTIONARY TO DATICAL_SCHEMA_OWNER_ROLE;` OR `permission to query v$pdbs and dba_data_files` See Roles and Permissions for Liquibase Enterprise on Oracle Database for further information on permissions. Property Validation: Source name should up to 30 characters long, contain no spaces [ ], slashes [/] and semicolons [;] and cannot begin with a number. Available in Liquibase 8.6 and later.
scmBranchHandling	SCM	Specifies how to handle branches in a multiple-branch project, one of two methods: scmswitch – use SCM-specific commands to switch branches in sqlScmPath directory – use a specified directory. When run against a pipeline, a pipeline-specific sqlScmPath is checked: <pipeline>.sqlScmPath=<path> When run against a dbdef, a dbdef-specific sqlScmPath is checked: <dbdef>.sqlScmPath=<path> If a pipeline-specific or dbdef-specific path is not provided, sqlScmPath is used. If sqlScmPath is also not specified, an error is returned. See "Pipeline and DbDef Branch Settings" below.
sqlScmBranch	SQL code files	The repository branch to be used for SQL code. Format varies by SCM: Git - branch name only
sqlScmDoCheckout	SQL code files	If this is not present or is set to `true`, Deployment Packager ensures that the local repository is up to date before packaging. To skip this operation, set to `false`. (Note that when setting this property to `false` that the DDB repo status will still be checked to make sure there aren't any uncommitted changes, but a pull/update/skip will not be performed.) Git - equivalent to `git pull`
sqlScmLastImportID	SQL code files	The SCM system ID for the most recently processed SQL code check in. It is automatically updated when the Deployment Packager completes successfully. Note: Do not leave blank. Do not use the most recent check-in. For first time use, use an ID from an earlier check-in. Git - first 8 digits of the hash
sqlScmPath	SQL code files	Path to the directory for SQL code in the local copy of the SCM repository. Can be an absolute path or path relative to the project directory. When packager determines the location of SQL code, it builds the location from sqlSCMPath and sqlScmSQLBaseDir. On Windows, backslashes must be doubled. Example: sqlScmPath=c:\\users\\username\\scmworkdir\\projectname
sqlScmSQLBaseDir	SQL code files	Top level directory for SQL code stored in the local copy of the repository. This is a name only, not a path. If set to '.' uses the value of sqlScmPath. This directory contains: Set of fixed-name sub-directories needed by Deployment Packager (ddl,data_dml,sql, and so on) Specially configured directories (See Flexible Folder Names.) Combination of fixed-name and flexible-name directories If not specified, a default directory name `sql_code` is used. When packager determines the location of SQL code, it builds the location from sqlSCMPath and sqlScmSQLBaseDir.
sqlScmSystem	SQL code files	SCM type – one of git
commitMsgLabelRegexp	SQL code files	By default, the Deploy Packager will scan the commit messages in your SQL code repo for values in square brackets. These values will be added as labels to the change sets that are produced by the files in that commit. For example: Commit Message: Adding column to hold area code information for [JIRA-1234] Change Set Label: JIRA-1234 If there is another pattern you would like to use for the designation of change set labels you can specify the regular expression for that pattern using this property. For example: commitMsgLabelRegexp=JIRA (\\d{6}) Commit Message: Adding column to hold area code information for JIRA 4321 which requires phone number separation Change Set Label: 4321 NOTE: If you provide a different pattern for matching desired label values, the values in square brackets will no longer be included as labels on change sets.
databaseBackupRestoreMethod	Backup	Class name to use for custom backup and restore. The class is implemented in a .groovy script. Class name BackupRestoreOracleDatapump is reserved. When set to this value, Deployment Packager uses Oracle Datapump API rather than the Oracle client and expdp/impdp utilities to perform the backups and restores during packaging. See Configuring Deployment Packager to Use the Oracle Datapump API for Backup and Restore. Class name BackupRestoreOracleFlashback is reserved. When set to this value, Deployment Packager uses Oracle Flashback rather than the Oracle client and expdp/impdp utilities to perform the backups and restores during packaging. See Configure Deployment Packager to Use the Oracle Flashback for Backup and Restore.
extensionsPath	Backup	Path to directory containing .groovy files that implement a custom backup and restore method. If not specified, the following directory is used: `<datical-install>/repl/scripts/extensions`.
databaseBackupMode	Backup	Specifies how to manage reference database backups that are required for deployments. always - (Default) Back up the database for every change deployment. The schema to be backed up may be limited by using the `schemaName` property in `metatdata.properties`. This is the most commonly used mode. on_demand - Back up the database only when a `deployPackager.groovy` command line option is used: `createDatabaseBackup=true`. This mode always backs up all* managed schema and the tracking schema.* This mode is intended as a special case for use with large databases that take a very long time to back up.
oracleBackupErrorWhitelist	Backup (Oracle Only)	A comma separated list of Oracle error codes to be ignored when evaluating expdp import/restore output for errors. (This property is only available with versions 7.18 and higher.) During an Oracle backup that uses local expdp / impdp clients OR the DATAPUMP API on the server, error messages are compared to the white-list: If any errors are found that do not exist in the white-list backup fails If the only errors found do exist in the white-list, backup completes successfully Example: oracleBackupErrorWhitelist=ORA-39173,ORA-39181
oracleRestoreErrorWhitelist	Restore (Oracle Only)	A comma separated list of Oracle error codes to be ignored when evaluating `impdp` import/restore output for errors. (This property is only available with versions 7.3 and higher.) During an Oracle restore that uses local expdp / impdp clients OR the DATAPUMP API on the server, error messages are compared to the white-list: If any errors are found that do not exist in the white-list restore fails If the only errors found do exist in the white-list, restore completes successfully Example: oracleRestoreErrorWhitelist=ORA-31684,ORA-39111,ORA-39151
parallel	Backup	Oracle only. Maximum of parallel threads for expdp and impdp to use during backup and restore.
archive	Processing	Archive SQL scripts in the archive directory after processing. This is done for SQL code in the ddl, sql_direct, data_dml directories. Archiving is done by default. Set to false to override the default behavior. If not set or if set to true, archiving is done as usual. The archive property has been deprecated. Instead it is preferable to set the newer rerunnable property in the metadata.properties of each relevant folder.
validateRollback	SQL code files	Test the rollback script provided for a SQL script (-rollback), unless set to none. The rollback script must be able to restore the database to its state before the SQL script was run. During testing, packager runs a test rollback and a test deploy from the rolled-back state. The test operations performed by packager are not logged to the Deployment Monitoring Console database (DMCDB). Available with Datical version 5.1 or higher. none - Do not test rollback scripts. withCompare - Test rollback scripts and their effect. During packaging, take a snapshot of the REF database to use for comparing database states to validate the rollback script. If the test fails, packager continues and shows a WARNING message in the log. withoutCompare - Test rollback scripts only to see if they run. Does not test their effects. If the test fails, packager exits with an ERROR. Note If you enable rollback validation, you must provide rollback files (-rollback) for all SQL scripts starting from when you enable it. You do not need to provide files for SQL scripts that have already been packaged and deployed. See Rollback File Validation During Packaging.
disableTraceFile	SQL code files	Oracle only. Controls whether the Oracle trace file is used. Default value is false. The option to disable trace file is only available in Datical versions 5.3 and higher. true - disables the use of the trace file false - enables the use of the trace file With tracefile turned on, Datical is able to detect and include the following additional SQL statement types during the CONVERT process (for Oracle Only): "create type", "create or replace type", "alter type", "drop type", "create materialized view", "alter materialized view", "drop materialized view", "create database link", "create shared database link", "create public database link", "create shared public database link", "drop database link", "drop public database link", "grant", "revoke", "insert", "update", "delete", select".
packageOrderStrategy	SQL code files	Specifies a custom package order, one of: DEFAULT - use the default ordering of commit order, then packageMethod, then alphanumeric PACKAGEMETHOD - use ordering by packageMethod, then alphanumeric ALPHANUMERIC - use ordering by alphanumeric only
skipCheckin	Project files, SQL code files	If this is not present or is set to `false`, Deployment Packager performs the final SCM operation to send changes from the local repository to the SCM server. To skip this operation, set to `true`. Git - skip the final `git push` (but still do the add and the commit)
ephemeralConnectionRetryTimeout	Backup (Azure SQL Managed Instance & Azure SQL DB only)	This setting defines an overall time (in minutes) that a Deploy Packager job should try to get a connection to the ephemeral database instance copy created for use in Azure SQL Managed Instance packaging. If the time expires and a successful connection cannot be made, Deploy Packager will fail. For more information see The ephemeralConnectionRetryTimeout property for Azure SQL Managed Instance

Sample deployPackager.properties files

Documented example deployPackager.properties file

deployPackager.properties

# This properties file controls the Datical DB deployPackager
sqlScmSystem=git
sqlScmLastImportID=421541c
sqlScmBranch=master
sqlScmPath=/home/developer/mySqlCode
sqlScmSQLBaseDir=sql_code

# the database backup restore location is on the db server.
databaseBackupRestoreLocation=

# Branch & Pipeline Specific Properties for Multiple Pipeline Projects
# Settings for the JUL_2016 Datical Deployment Pipeline
JUL_2016.sqlScmBranch=JUL_2016_SQL
JUL_2016.sqlScmLastImportID=75782c

#Settings for the AUG_2016 Datical Deployment Pipeline
AUG_2016.sqlScmBranch=AUG_2016_SQL
AUG_2016.sqlScmLastImportID=49628d

#Settings for the PROD_STAGING Database Definition
PROD_STAGING.sqlScmBranch=AUG_2016_SQL
PROD_STAGING.sqlScmLastImportID=69371n

Sample deployPackager.properties file included in the product

A sample deployPackager.properties file is included in the DaticalDB installation in directory <datical-install>\DaticalDB\repl\scripts\. You can copy it to each of your project directories and edit it for each project.

# This is a sample deployPackager properties file.
#
# There are two sets of SCM information that can be supplied. The first specifies
# the location of the SQL files that will be packaged - these start with "sqlScm".
# The second is for the Datical DB project itself and has property names that start
# with "ddbScm".
#
# In addition to SCM properties, you can also supply a location for database backups.
#
# The following properties can be set in the deployPackager.properties file:
#
# sqlScmSystem - SCM software type for SQL code - currently supported types
# are git. Required. No default.
#
# sqlScmPath - Local directory path to the developer's SCM working copy for
# SQL code. Can be absolute, or relative to the directory
# where the Datical DB project is.
# If using multiple branches, see the section below for more
# details.
# Note that When used on Windows, backslashes MUST be doubled,
# because the \ character is an escape character. Proper Windows
# statement for this would look like this:
# sqlScmPath=c:\\users\\username\\scmworkdir\\projectname
#
# sqlScmBranch - The repository branch to be used for SQL code. The format of
# this value is dependent on the SCM system being used.
# git - just supply the branch name
# If using multiple branches, see the section below for more
# details.
#
# sqlScmLastImportID - The SCM system's "id" for the most recently processed SQL
# code check in. This will be automatically updated when the
# deploy packager completes successfully.
# For Git, this is the first 8 digits of the relevant hash
# Note: Do not leave blank. Do not use the most recent
# checkin. For first time use, use an ID from an earlier checkin.
# If using multiple branches, see the section below for more
# details.
#
# sqlScmSQLBaseDir - Top level directory for the SQL scripts stored in the
# developer's SQL SCM working copy. This is just the name of a
# single directory. Can be the character '.' to specify that
# the directory specified by sqlScmPath is a directory that
# contains the sub-directories (ddl,data_dml,sql,sqlplus,
# sql_direct,function,procedure,package,packagebody,trigger)
#
# sqlScmDoCheckout - If this is not present or is set to 'true', deploy packager
# will ensure that the latest available revision of the SQL
# repository is retrieved before processing. Set this to
# 'false' to skip this.
# For users using git, this is equivalent to 'git pull'
#
# ddbScmSystem - SCM software type for the Datical DB project. Currently
# supported types are git. May be different than
# the sqlScmSystem. If this is not present, deploy packager
# will use the value from sqlScmSystem.
#
# ddbScmPath - Local absolute directory path to the developer's Datical DB SCM
# working copy. If this is not present, deploy packager will
# use the value from sqlScmPath.
# Note that When used on Windows, backslashes MUST be doubled,
# because the \ character is an escape character. Proper Windows
# statement for this would look like this:
# ddbScmPath=c:\\users\\username\\scmworkdir\\projectname
#
# ddbScmBranch - The branch to be used for the Datical DB project. If this
# is not present, deploy packager will use the value from
# sqlScmBranch. See the description for sqlScmBranch for examples
# of valid values.
#
# ddbScmDoCheckout - If this is not present or is set to 'true', deploy packager
# will ensure that the latest available revision of the
# Datical DB repository is retrieved before processing. Set
# this to 'false' to skip this. If this is not present,
# deploy packager will use the value from sqlScmSystem.
# For users using git, this is equivalent to 'git pull'
#
# parallel - ORACLE-ONLY: The number of parallel threads that can be
# used by expdp/impdp when doing backup/restore
#
# databaseBackupRestoreLocation -
# During packaging, the script will make backups
# of the database. These are usually stored on the database
# server itself. This property specifies the location to which
# the database backup should be written. Depending on your
# DBMS, this may need to be a directory or it may need to
# be a file.
# Note: On Oracle and DB2, this directory will be on the
# server, so the path separator must follow the server's
# convention ('/' on Linux, '\' on Windows.) Because the
# '\' is an escape character in Java properties files, you
# must supply '\\' to indicate a single backslash.)
#
# databaseBackupRestoreMethod
# - This property can be used to load custom backup/restore scripts.
# - ORACLE-ONLY: Set to BackupRestoreOracleDatapump to use the
# Oracle Datapump API directly instead of the expdb/impdb
# command line tools.
# - ORACLE-ONLY: Set to BackupRestoreOracleFlashback to use the
# Flashback instead of the expdb/impdb
# command line tools.
#
# databaseBackupMode
# - always (default) - A backup of the reference database will
# be taken for every run of deploy packager. If a failure
# occurs during packaging, the reference database will be restored
# to this backup file. This does not apply to feature merge
# packaging where a dbDef is provided.
# - on_demand - A backup of the reference database will only be taken
# when a command line parameter of createDatabaseBackup=true
#
# When working with multiple branches in the sqlScm repository, there are
# additional pipeline-specific and dbDef-specific properties that can be set, as
# well as a property that controls how scm branching is handled.
#
# scmBranchHandling - This property can be set to either 'directory' or
# 'scmswitch'. If it is not present, then deployPackager will
# behave as if 'scmswitch' has been set.
# When set to 'directory', deployPackager will use different
# working copies that should each contain sql code
# corresponding to a particular SCM branch. This is most
# useful for SCM systems that pose
# difficulties when working with multiple branches. When set
# to 'directory' then you will also need to set
# pipeline_name.sqlScmPath and/or dbDef_name.sqlScmPath
# properties as described below.
# When this is set to 'scmswitch' or if this property is not
# set, then deployPackager will use the path specified by
# sqlScmPath as a single working copy, and will use SCM
# specific commands to switch that working copy to use the
# appropriate branch that is specified using the
# pipeline_name.sqlScmBranch and/or dbDef_name.sqlScmBranch
# properties. This setting is most appropriate when using
# git as the SCM tool.
#
# pipeline_name.sqlScmPath -
# Local directory path to the developer's SCM working copy,
# on the branch that corresponds to the given pipeline, for
# SQL code. Can be absolute, or relative to the directory
# where the Datical DB project is.
# Note that When used on Windows, backslashes MUST be doubled,
# because the \ character is an escape character.
#
# pipeline_name.sqlScmBranch -
# The repository branch to be used for SQL code. The format of
# this value is dependent on the SCM system being used.
# git - supply the branch name
#
# pipeline_name.sqlScmLastImportID -
# The SCM system's "id" for the most recently processed
# Datical DB project check in on the branch corresponding to
# the given pipeline_name. This will be automatically
# updated when the deploy packager completes successfully.
# For Git, this is the first 8 digits of the relevant hash
# Note: Do not leave blank. Do not use the most recent
# checkin. For first time use, use an ID from an earlier checkin.
#
# dbDef_name.sqlScmPath - Local directory path to the developer's SCM working copy,
# on the branch that corresponds to the given dbDef, for
# SQL code. Can be absolute, or relative to the directory
# where the Datical DB project is.
# Note that When used on Windows, backslashes MUST be doubled,
# because the \ character is an escape character.
#
# dbDef_name.sqlScmBranch -
# The repository branch to be used for SQL code corresponding
# to the given dbDef_name. The format of this value is
# dependent on the SCM system being used.
# git - supply the branch name
#
# dbDef_name.sqlScmLastImportID -
# The SCM system's "id" for the most recently processed
# Datical DB project check in on the branch corresponding to
# the given dbDef_name. This will be automatically updated
# when the deploy packager completes successfully.
# For Git, this is the first 8 digits of the relevant hash
# Note: Do not leave blank. Do not use the most recent
# checkin. For first time use, use an ID from an earlier checkin.
#
# ddlExcludeList Comma separated list of database object types to exclude from snapshot
# This may be the values 'all', 'none', or combinations of:
# 'procedure', 'function', 'package', 'packagebody', 'trigger', 'view'
# 'non_stored_logic' value can be used to exclude all non stored logic database objects from generated snapshot
# Please note, the 'all' value will exclude only stored logic database objects from generated snapshot.
#
# archive If this is not present or is set to 'true', deploy packager will
# archive successfully processed SQL files after packaging.
# If set to false, no archiving will occur.
#
# packageOrderStrategy -
# DEFAULT - this is the default strategy that is set if the property is
# not specified. This preserves the commit order while packaging.
# PACKAGEMETHOD - packaging order is based on the packageMethod first
# and then by path/filename
# ALPHANUMERIC - packaging order is based strictly on path/filename
#
# skipCheckin - If this is not present or is set to false, Deployment Packager performs
# the final SCM operation to send changes from the local repository to
# the SCM server. To skip this operation, set to true.
# git - skip the final git push (but still do the add and the commit)
#
# commitMsgLabelRegexp -
# By default, the Deploy Packager will scan the commit messages in your SQL code repo
# for values in square brackets. These values will be added as labels to the change sets
# that are produced by the files in that commit.
# For example:
# Commit Message: Adding column to hold area code information for [JIRA-1234]
# Change Set Label: JIRA-1234
# If there is another pattern you would like to use for the designation of change set labels
# you can specify the regular expression for that pattern using this property.
# For example: commitMsgLabelRegexp=JIRA (\\d{6})
# Commit Message: Adding column to hold area code information for JIRA 4321 which requires phone number separation
# Change Set Label: 4321
#
# oracleBackupErrorWhitelist -
# A comma separated list of Oracle error codes to be ignored
# when evaluating expdp output for errors. During an Oracle backup that uses
# local expdp / impdp clients OR the DATAPUMP API on the server,
# error messages are compared to the white-list:
# If any errors are found that do not exist in the white-list restore fails
# If the only errors found do exist in the white-list, restore completes successfully
# For example:
# oracleRestoreErrorWhitelist=ORA-31684,ORA-39111,ORA-39151
#
# oracleRestoreErrorWhitelist -
# A comma separated list of Oracle error codes to be ignored
# when evaluating impdp output for errors. During an Oracle restore that uses
# local expdp / impdp clients OR the DATAPUMP API on the server,
# error messages are compared to the white-list:
# If any errors are found that do not exist in the white-list restore fails
# If the only errors found do exist in the white-list, restore completes successfully
# For example:
# oracleRestoreErrorWhitelist=ORA-31684,ORA-39111,ORA-39151
# oracleBackupNoCrossSchemaFk -
# A boolean flag to turn off cross-schemas foreign keys back up. Default value is 'false'.
# oracleBackupNoGrants -
# A boolean flag to turn off grants back up (for directory, table and column). Default value is 'false'.
# oracleBackupNoDropSchema -
# A boolean flag to turn off the dropping of schemas after back up done
# before restore (use 'dropAll(dbObjects)' instead). Default value is 'false'.
#
# ephemeralConnectionRetryTimeout -
# Defines an overall time to get the connection to the Ephemeral database instance
# after the backup operation is executed. Default value is 20 minutes.
#
sqlScmSystem=
sqlScmLastImportID=
sqlScmBranch=
sqlScmPath=
sqlScmSQLBaseDir=
ddbScmSystem=
ddbScmBranch=
ddbScmPath=
databaseBackupRestoreLocation=
databaseBackupMode=
parallel=
ddlExcludeList=
archive=
packageOrderStrategy=
skipCheckin=
commitMsgLabelRegexp=
oracleBackupErrorWhitelist=
oracleRestoreErrorWhitelist=
oracleBackupNoCrossSchemaFk=
oracleBackupNoGrants=
oracleBackupNoDropSchema=
ephemeralConnectionRetryTimeout=

Liquibase Enterprise Documentation Home

Use the Required deployPackager.properties File