How To: Setup Dynamic Branch Names

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.

\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.

Unsupported Scenario

Branch_A is created from main branch.
Branch_B is created from main branch and is now ahead of main by 2 commits.
The deployPackager.properties is configured with the sqlScmLastImportID from Branch_B.
Branch_A will not be able to package successfully because the commit specified in the deployPackager.properties cannot be located by git log as it does not share a common ancestor.

\uD83D\uDCCB Related articles

Please see the related documentation

Use the Required deployPackager.properties File