Resolving Configuration Verifier Deltas

After running the Configuration Verifier, or CV in short, the reported delta definitions need to be reviewed and ideally all be resolved before deploying the new project configuration, in production, or for validating a local upgrade of an existing (production copy) repository first.

Before trying to resolve the delta definitions though, especially when working through an upgrade from CMS v11 to v12, make sure to read and understand the Upgrade Considerations document first!

Resolving a delta definition

In general, each delta definition should be categorized into:

• Desired or intended, caused by the updated or upgraded configuration.
  In that case add the delta definition path to the ignorepaths section of the configuration-verifier-config.yaml.
• Runtime changes
  • in config
    • which you want to preserve.
      Incorporate them into your project's config definitions and run CV again to make sure the delta is no longer reported.
    • which you don't want or need to preserve.
      Add the path to the ignorepaths of the configuration-verifier-config.yaml.
  • in content
    The fact that the delta is reported means that the configuration model still considers the node(s) config.
    Add a .meta:category: content or .meta:residual-child-node-category: content to your project's config definitions to categorize the (parent) node of your delta definition as content, and run CV again to make sure the delta is no longer reported.
  •  in system.
    The fact that the delta is reported means that the configuration model still considers the node or property config.
    Add a .meta:category: system or .meta:residual-child-node-category: system to your project's config definitions to categorize the node or property of your delta definition system, and run CV again to make sure the delta is no longer reported.