How To: Create a Common Rules Repository

Introduction

The below steps outline how a common rules repository can be setup with Packager automation. This configuration allows customers to maintain rules at a corporate or global level versus having rules stored at the individual project level. This method has several advantages including:

• Rules standardization

• Modification to rules only need to be made in one location

Additionally this page describes additional configurations:

• Add project-specific rules in conjunction with a common rules repository

• Override global-level rules for a particular project

Steps

1. Create an SCM repository to house the Liquibase Enterprise Rules. For this example the repository is called liquibase-centralized-rules.

   1. Add folders to this repository for Forecast, PostForecast, PreForecast, and SqlRules.

   2. Copy the desired rules into the appropriate folders from a Liquibase Enterprise project.

   3. Push the changes to the new repository. In this example we are using branch main for the changes.

2. Remove the Rules folders from the DDB repository.

   1. Push this change to the existing DDB repository.

   2. Note: Step 2 does need to occur prior to Step 3 in order for the file deletions to be detected by SCM.

3. Add the Rules folder to the .gitignore for the DDB repository. The Packager automation script will be copying files into the Rules folder so the folder needs to be added to the .gitignore to prevent SCM changes from being detected there.

   1. Add to .gitignore

      Rules/

   2. Push this change to the existing DDB repository.

4. Update the packager automation script to clone the Liquibase Enterprise Rules repository and checkout the main branch.

   1. Do this step AFTER checkout of the DDB repository.

   2. If using Jenkins, you can clone the rules repository and copy the files directly into the target directory with the checkout command. The target directory will be the Rules folder of the DDB repository.

      // checkout Rules from Rules repo checkout([ $class: 'GitSCM', branches: [ [name: '*/main'] ], doGenerateSubmoduleConfigurations: false, extensions: [ [$class: 'RelativeTargetDirectory', relativeTargetDir: "${DDB_REPO}/Rules"], [$class: 'LocalBranch', localBranch: 'main'] ], gitTool: 'Git - Windows', submoduleCfg: [], userRemoteConfigs: [ [credentialsId: 'Liquibase', url: "${GITURL_RULES}"] ] ])

   3. Other tools may require cloning the rules repository and then copying the Rules folder from the rules repository into the ddb repository using shell commands, eg.

      cp -R <path_to_rules_repo>/liquibase-centralized-rules/Rules <path_to_ddb_repo>/.

5. The hammer packager command should be able to run without any modifications. The rules from the common rules repository will be in place in the Rules folder of the project. Packager should not detect any SCM changes to this folder because it is present in the .gitignore.

Add project-specific rules in conjunction with a common rules repository

1. Perform Steps above to setup to setup a common rules repository.

2. Create a folder called ProjectRules in the DDB repository.

   1. Add folders to this folder for Forecast, PostForecast, PreForecast, and SqlRules.

3. Add any project-specific rules to these folders beneath ProjectRules.

4. In the packager automation script, after the Steps above that copy the common rules into the DDB repository do the following:

   1. Use shell commands to copy the rules from ProjectRules into Rules of the DDB repository.

      1. Windows

      2. Linux

5. The hammer packager command should be able to run without any modifications. The rules from the common rules repository will be in place in the Rules folder of the project with additional project-specific rules included as well.

Override global-level rules for a particular project

1. Perform Steps above to setup to setup a common rules repository.

2. Create a folder called ProjectRules in the DDB repository.

   1. Add folders to this folder for Forecast, PostForecast, PreForecast, and SqlRules.

3. For any rules you wish to modify, use the same rule name as what is present in the common rules repository.

   1. Make the necessary code adjustments to the rule.

4. Place the project-specific rule in the appropriate folder beneath ProjectRules.

5. In the packager automation script, after the Steps above that copy the common rules into the DDB repository do the following:

   1. Use shell commands to copy the rules from ProjectRules into Rules of the DDB repository.

      1. Windows

      2. Linux

6. The hammer packager command should be able to run without any modifications. The rules from the common rules repository will be in place in the Rules folder of the project with any project-specific overrides having replaced the common rule.

Tips for modifying rules:

• If you just wish to turn off a rule for a particular project, you can switch the ResponseType from FAIL or WARN to PASS.