You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
actions:
- name: open
description: opens
- name: close
description: closes
- name: idle
description: idles
fields:
- name: date
description: date of action
- name: which
description: which item
# mapping incompleteness is intentional
coverage_map:
open:
which: one
date: today
close:
which: one
The specific actions and fields defined in this sample are not likely to be anywhere close to the actions and fields that would be in a different sample, but the requirement that the top level keys should be actions and the inner keys be fields will hold true for them all. Consequently, it would be very hard to follow the advice of the maintainer in #71 since the way I interpret what they're saying would imply needing to create a schema for each file, which defeats the purpose of having a schema in the first place.
Unless I'm missing something, it seems like having an 'in' validator would be the only way to make my usecase possible. Is this something that yall would be willing to add as a built-in validator?
The text was updated successfully, but these errors were encountered:
where you would add all possible values to the enum validators (I only included the ones in your sample).
If you want the keys to only be one of the action and field names present in the yaml file being validated you either need a schema per file or create a custom validator/constraint.
Hi folks, first just wanted to say that I appreciate this project. It's been useful in applying any amount of order at all to our yaml files.
I'm trying to make a schema as follows:
Sample file:
The specific actions and fields defined in this sample are not likely to be anywhere close to the actions and fields that would be in a different sample, but the requirement that the top level keys should be actions and the inner keys be fields will hold true for them all. Consequently, it would be very hard to follow the advice of the maintainer in #71 since the way I interpret what they're saying would imply needing to create a schema for each file, which defeats the purpose of having a schema in the first place.
Unless I'm missing something, it seems like having an 'in' validator would be the only way to make my usecase possible. Is this something that yall would be willing to add as a built-in validator?
The text was updated successfully, but these errors were encountered: