Difference between revisions of "Yamllint"
(add content on how to use comment directives in yamllint) |
(add several more command switches to the 'tips'; change tips to cheatsheet) |
||
| Line 2: | Line 2: | ||
Of course, you should have one in your local tools and CI pipeline to ensure that your [[YAML]] is always correct. With the yamllint, there is both a script and a Python module; meaning you can write your own linting tool in Python by invoking (importing) the yamllint module<ref>https://yamllint.readthedocs.io/en/stable/development.html</ref>. See the caveat section below about "using the right tool for the job" - meaning use the right linter for the language/project you are linting. | Of course, you should have one in your local tools and CI pipeline to ensure that your [[YAML]] is always correct. With the yamllint, there is both a script and a Python module; meaning you can write your own linting tool in Python by invoking (importing) the yamllint module<ref>https://yamllint.readthedocs.io/en/stable/development.html</ref>. See the caveat section below about "using the right tool for the job" - meaning use the right linter for the language/project you are linting. | ||
| + | |||
| + | {{Notice|If you have a <tt>.yamllint</tt> file in your working directory, it will be automatically loaded as configuration by yamllint.}} | ||
| + | |||
==Manually fix errors== | ==Manually fix errors== | ||
Unfortunately, <tt>yamllint</tt> does not fix your file for you. There could be ambiguities about the proper fix, so you need to do the fix(es) yourself. | Unfortunately, <tt>yamllint</tt> does not fix your file for you. There could be ambiguities about the proper fix, so you need to do the fix(es) yourself. | ||
| − | == | + | ==Cheatsheet== |
You can use '''[https://yamllint.readthedocs.io/en/stable/disable_with_comments.html comment directives]''' to control the behavior of <code>yamllint</code> | You can use '''[https://yamllint.readthedocs.io/en/stable/disable_with_comments.html comment directives]''' to control the behavior of <code>yamllint</code> | ||
| Line 26: | Line 29: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
| + | <code>--no-warnings</code> will suppress the warnings so you can focus only on errors. | ||
| + | |||
| + | <code>--list-files</code> will show you the list of files that yamllint finds (and would otherwise lint). | ||
| + | |||
| + | <code>--format</code> (or <code>-f</code>) gives you options for how you want the output to display. | ||
| + | |||
==Many linters== | ==Many linters== | ||
You can't just use "one" solution either<ref>https://phabricator.wikimedia.org/T95890</ref>. The leading GPL linter is based on Python, so depending on your code repo, you may instead want to use a JavaScript or PHP implementation. Thus, tools like [[wp:Grunt (software)]] may be used to automate JSHint linting in [[JavaScript]] projects<ref>https://www.codereadability.com/jshint-with-grunt/</ref>. | You can't just use "one" solution either<ref>https://phabricator.wikimedia.org/T95890</ref>. The leading GPL linter is based on Python, so depending on your code repo, you may instead want to use a JavaScript or PHP implementation. Thus, tools like [[wp:Grunt (software)]] may be used to automate JSHint linting in [[JavaScript]] projects<ref>https://www.codereadability.com/jshint-with-grunt/</ref>. | ||
Revision as of 14:35, 20 January 2024
Use an online validator like https://www.yamllint.com/ or https://jsonformatter.org/yaml-validator
Of course, you should have one in your local tools and CI pipeline to ensure that your Yaml is always correct. With the yamllint, there is both a script and a Python module; meaning you can write your own linting tool in Python by invoking (importing) the yamllint module[1]. See the caveat section below about "using the right tool for the job" - meaning use the right linter for the language/project you are linting.
 | If you have a .yamllint file in your working directory, it will be automatically loaded as configuration by yamllint. |
Manually fix errors[edit | edit source]
Unfortunately, yamllint does not fix your file for you. There could be ambiguities about the proper fix, so you need to do the fix(es) yourself.
Cheatsheet[edit | edit source]
You can use comment directives to control the behavior of yamllint
With disable-line you put the directive in-line, or on the line above.
# The following mapping contains the same key twice,
# but I know what I'm doing:
key: value 1
# yamllint disable-line rule:key-duplicates
key: value 2
# yamllint disable-line rule:line-length
- This line is waaaaaaaaaay too long but yamllint will not report anything about it.
This line will be checked by yamllint.
With disable you can disable multiple rules for the entire file.
# yamllint disable rule:hyphens rule:commas rule:indentation
Or even use disable-file
# yamllint disable-file
# This file is not valid YAML because it is a Jinja template
--no-warnings will suppress the warnings so you can focus only on errors.
--list-files will show you the list of files that yamllint finds (and would otherwise lint).
--format (or -f) gives you options for how you want the output to display.
Many linters[edit | edit source]
You can't just use "one" solution either[2]. The leading GPL linter is based on Python, so depending on your code repo, you may instead want to use a JavaScript or PHP implementation. Thus, tools like wp:Grunt (software) may be used to automate JSHint linting in JavaScript projects[3].
Source, Docs and Reading[edit | edit source]
- https://github.com/adrienverge/yamllint
- https://yamllint.readthedocs.io/en/stable/
- https://www.redhat.com/sysadmin/check-yaml-yamllint
