ValidationsEvery time a data changeset is being approved, SWEAGLE applies a set of validation policies to ensure that the changes (additions, modifications, deletions) are not causing any issues. By approving a data changeset Sweagle calculates the validation status for the "pending status". This allows us to first check the validation results before storing the changes as a snapshot for every configData set. In case there are issues detected, the user can open another data changeset and correct the configData. This process can be repeated several times until all issues are resolved. Base validations Base validations are built-in validation policies that can be activated through the tenant preferences and do not require any additional configuration. Sweagle offers various types of base validations that are applied to each of the config data sets with pending data: unidentified token: verifies that in the scope of the config data set (CDS), all tokens can be resolved. invalid config data: verifies that the value is according to the list of allowed values (regex, value list).missing config data: verifies that all config data items exist for the type of node. If a node is of type "server" and the attribute "internal IP" is missing then this will throw a "missing config data" violation. conflicting config data: verifies if the same config data keyName appears multiple times, and if so if the assigned values are different. duplicate config data: verifies if the same config data keyName appears multiple times. Custom validations Custom validation policies allow customers to write conditional logic that validates if a config data set is compliant or not. Validations policies are written in javascript and managed through the SWEAGLE user interface by users of type "Admin". The validation policies are assigned to the config data sets for which they are relevant, and a single config data set can have multiple validation policies assigned. The custom validation policies are executed upon approval of a data changeset and for every config data set that is impacted by that approval. All validation policies are executed, even when the first one already results in a violation issue. The result of the validations is shown for every config data set under the "pending" menu option. A library with sample validators is publicly available on the SWEAGLE github account Arguments A validation policy can take input arguments. At the time of assigning the validator to a CDS, the user can set the arguments in a string object. We recommend using a JSON notation for the argument values. This allows us to have generic validator policies that can be provided with CDS specific values without the need to change the validation logic. More information can be found in KB0854368 - Validations - variable input Multi-CDS validators A validation policy can take multiple CDS as an input. At the time of assigning a validator to a CDS, the user can select additional CDS. The validation policy can apply a logic that spans the multiple CDS content such as a comparison that the dbConnectionString between the test environment CDS is not the same as the one in the production environment CDS. Note that the validation status is calculated and stored specifically for the primary CDS to which the validator is assigned. When a validation policy fails, it will only store that validation error to the primary CDS and not on the additional CDS that are used in the validation policies. more information can be found KB0854370 - Multi CDS validators. API for validations There are several API calls available to integrate the SWEAGLE configData validation as part of your CD pipeline. See "KB0854286 - retrieve CDS validation status" and "KB0854287 - API - run validator rule" Tenant system settings Users of type admin can control the behavior of the continuous configData validations in SWEAGLE through settings under "admin/preference" : the level of error that is thrown for each of the base validations: off, warn, errortrigger automatically, or run manually: calculate_snapshots.validation.level