As discussed in #65, it may be useful to add a command that attempts to validate that a board or shield configuration is defined correctly to work with ZMK. I don't think it makes sense to try to build a full kconfig/devicetree linting system, but there are a few things that would be relatively simple to check and are easy errors to make.
Things we could check for boards and shields:
- Does the .zmk.yml file match the schema?
- If a board has a
default_revision, does a matching revision exist in its revisions list?
- For every board/shield sibling, board variant, and board revision, do all of the non-optional kconfig and devicetree files exist?
- Are there any name collisions? (Often caused by copying a board/shield into your config and not renaming it.)
The validation command could support a list of .zmk.yml files to check or default to scanning all of them.
There are also a few things in the root build.yml file that we could validate as well, such as verifying that every board, shield, and snippet used in the build matrix exists. I'm not sure whether that should be part of the same command as checking boards/shields or a separate one if we were to do this though.
As discussed in #65, it may be useful to add a command that attempts to validate that a board or shield configuration is defined correctly to work with ZMK. I don't think it makes sense to try to build a full kconfig/devicetree linting system, but there are a few things that would be relatively simple to check and are easy errors to make.
Things we could check for boards and shields:
default_revision, does a matching revision exist in its revisions list?The validation command could support a list of .zmk.yml files to check or default to scanning all of them.
There are also a few things in the root build.yml file that we could validate as well, such as verifying that every board, shield, and snippet used in the build matrix exists. I'm not sure whether that should be part of the same command as checking boards/shields or a separate one if we were to do this though.