Validate YAML configuration using CLI

Learn how to use the YAML configuration CLI to validate a YAML configuration.

3 minute read

The validate option may be used to validate YAML configurations. Both full configurations, and configuration fragments may be validated in the same way.

Validate configuration changes in the YAML configuration

You can validate a YAML configuration that was generated by converting an XML federated configuration, or an XML configuration fragment. After the conversion step, you can make changes to the YAML configuration and perform further validation checks before deployment.

To make changes to your YAML configuration files, use an IDE or editor of your choice. Your editor can assist with ensuring that the YAML is valid and properly indented. The yamles validate option can assist to ensure that the content you have added or modified is valid according to the Entity Store model. The error content will point towards the YAML file where the problem is located.

The following are examples of how you can Validate a YAML configuration in the yamles CLI.

Example 1: Specify the directory containing the YAML configuration:

./yamles validate --source /home/user/yaml

Example 2: Specify a URL:

./yamles validate --source yaml:file:/home/user/apiprojects/myyaml

Example 3: Specify a URL and passphrase to validate an encrypted YAML configuration:

./yamles validate --source yaml:file:/home/user/apiprojects/myyaml --passphrase changeme

Example 4: Specify a .tar.gz file:

./yamles validate --source /home/user/archives/myconfig.tar.gz

You can run the following help command for more details on each parameter:

yamles validate --help

The --source parameter might also be used to validate multiple YAML configurations in one run. For example, if you converted all your XML Policy Studio projects in the apiprojects directory to YAML with --output-dir of yaml-apiprojects parameters, you can point to your yaml-apiprojects directory and all projects will be validated.

Disable entity reference check

In some cases, you might have a valid configuration that points to an entity that exists in another configuration. This is the case for Team Development when you want to keep common configuration in a separate project for reuse purposes. You might need to validate each configuration separately before merging without generating errors for fields that point to entities that exist elsewhere. This might also occur for configuration fragments if they were generated without full closure, which means entities referred to by selected entities are not included in the fragment. Use the --allow-invalid-ref option to ensure that an error is not generated in this case. With this parameter enabled, warnings are traced but no error is generated.

To learn how to solve validation errors, see known validation errors. Note that errors are shown on stdout. Warnings will only be listed on stdout if there are other errors and if only warnings are found, they are listed in the trace file only.