

Well, your development environment can help you. Such a long feedback cycle could easily lead to git commit -m "Fuck YAML" in your commit history and a subsequent amend/rebase/squash dance (and you can’t squash the obscene commit notifications sent to the rest of your team!). You need to commit and push to run your tests, spin up VMs or containers, dive into Ruby code, and write tests for all possible pillar/grain permutations. A helpful guide on this topic is available here. Test your states using Test Kitchen together with kitchen-salt and some verifier. This triggers the state rendering process and can catch tons of possible errors. Use the salt-call -local -retcode-passthrough state.show_sls YOUR_STATE either manually or using a commit hook. For Salt, you have the following options: Indeed, it is possible to validate your states, in a semi- or completely automated way, even before they touch your infrastructure.

Smart developers probably have this figured out, right? These issues definitely have come up before ( #802). Sprinkle a few Jinja tags here and there, and the errors can get even fancier… Is there anything that could be done?

A ParserError or ScannerError while running the state.highstate.Data failed to compile: State ‘foo’ in SLS ‘bar’ is not formed as a list.A missing colon after the YAML key or a missing space after the colon.If you have ever written a couple of Salt states, these problems may sound familiar: Text editor plugins for Salt states and YAML/Jinja
