This article demonstrates how to use dynamic branch names instead of specifying static names in the deployPackager.properties file. The configuration uses directory mode scmBranchHandling instead of scmswitch mode (which is the default if not specified).
Use Cases for Dynamic Branch Names
Dynamic Branch names can be advantageous in the following scenarios.
Scenario 1: Teams do not use long-lived branches for builds
Teams whose branch names change with each build or release may find it inconvenient to update the deployPackager.properties file when the branch name changes.
Scenario 2: Teams sharing a Liquibase Project do not want to be blocked by packaging errors from another team
If a developer has checked-in a file that causes a packaging error for a particular branch, that branch/pipeline is essentially blocked until the developer fixes the script causing the error. Dynamic branch names allow another team or individual to package their changes using a different code branch even if another branch has an error.
Scenario 3: Teams want to test their changes prior to check-in to a shared branch
If you wish to provide an avenue for teams to validate their SQL changes prior to check-in to a shared or protected branch you may wish to consider using dynamic branch names.
\uD83D\uDCD8 Instructions
In the deployPackager.properties file of the DDB project repo add (or modify if property already exists)
scmBranchHandling=directory
Comment out or remove any existing sqlScmBranch name attributes. Note: the sqlScmLastImportID is required for both directory and scmswitch mode.
#dev.sqlScmBranch=development dev.sqlScmLastImportID=e1f05bc #release.sqlScmBranch=release release.sqlScmLastImportID=01cfac3
Commit the changes above to your Liquibase Project git repository.
In your CI/CD automation tool, perform a check-out of the desired sqlScmBranch with each packing operation. When using directory mode scmBranchHandling, Liquibase Enterprise will not automatically perform a branch check-out for the SQL Repository. Instead it packages on the SQL Repository’s branch that it present in the workspace at the time of the packaging operation.
In your CI/CD automation tool, ensure that only one packager operation is running at a time for a single pipeline (or multiple pipelines sharing a REF db.) This is because multiple backup/restore operations cannot run in parallel on a REF db.
\uD83D\uDCD8 Merging
When using directory mode branch handling it is important that commit specified in sqlScmLastImportID can be found in the git log history for the branch. It does not need to exist on the branch itself, but it must share a common ancestor.
Branches should be created from a common ancestor branch, eg. main, in order for git log to locate the sqlScmLastImportID in the history. Ideally teams should regularly merge their code branches back to a long-lived branch and all branches should be created from this long-lived branch.
Supported Scenario
The deployPackager.properties is configured with the sqlScmLastImportID from main branch.
Branch_A is created from main branch.
Branch_B is created from main branch.
Branch_A packages successfully and the deployPackager.properties is updated by Liquibase Enterprise with a new sqlScmLastImportID located on Branch_A.
Branch_B does not have the new sqlScmLastImportID directly in it’s git commit history, but this commit can be located by git log because it shares a common ancestor.
Git command
The git command used to get the history of commits on a branch is below.
git log --reverse --pretty=format:'%h, %an, %s' --abbrev-commit <sqlScmLastImportID>..HEAD
\uD83D\uDCCB Related articles
Please see the related documentation