Validate YAML configuration using CLI
3 minute read
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
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
./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
--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
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.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.