Make sure values passed in allowed values are correct ones. This is
possible thanks to previous commit, and should prevent users from
writing incorrect configurations.
Allow rules to declare a list of valid values for an option.
For example, a rule like:
CONF = {'allowed-values': list}
... allowed any value to be passed in the list (including bad ones).
It is now possible to declare:
CONF = {'allowed-values': ['value1', 'value2', 'value3']}
... so that the list passed to the options must contain only values in
`['value1', 'value2', 'value3']`.
Allows using key `allowed-values` for `truthy` section in configuration file (#150).
This allows to use configuration `truthy: allowed-values: ["yes", "no",
"..."]`, to set custom allowed truthy values.
This is especially useful for people using ansible, where values like
`yes` or `no` are valid and officially supported, but yamllint reports
them as illegal.
Implemented by difference of set of TRUTHY constants and configured
allowed values.
Signed-off-by: Ondrej Vasko <ondrej.vaskoo@gmail.com>
Some usages of YAML (like Ansible) supports running the file as a script.
Support (by default) an ignore-shebangs setting for the comments module.
Fixes#116 - comments rule with require-starting-space: true should special case shebang
Before, it was required to specify all the options when customizing a
rule. For instance, one could use `empty-lines: enable` or `empty-lines:
{max: 1, max-start: 2, max-end: 2}`, but not just `empty-lines: {max:
1}` (it would fail with *invalid config: missing option "max-start" for
rule "empty-lines"*).
This was a minor problem for users, but it prevented the addition of new
options to existing rules, see [1] for an example. If a new option was
added, updating yamllint for all users that customize the rule would
produce a crash (*invalid config: missing option ...*).
To avoid that, let's embed default values inside the rules themselves,
instead of keeping them in `conf/default.yaml`.
This refactor should not have any impact on existing projects. I've
manually checked that it did not change the output of tests, on
different projects:
- ansible/ansible: `test/runner/ansible-test sanity --python 3.7 --test yamllint`
- ansible/molecule: `yamllint -s test/ molecule/`
- Neo23x0/sigma: `make test-yaml`
- markstory/lint-review: `yamllint .`
[1]: https://github.com/adrienverge/yamllint/pull/151
`-f standard` shows non-colored output,
`-f colored` shows colored output,
`-f auto` is the new default, it chooses `standard` or `colored`
depending on terminal capabilities.
Original implementation was completely broken. Documentation and actual
behavior were different. Numbers and booleans were detected as wrong, as
well as explicit types.
Fixes#136 and #130.
To test yamllint as a module, tests run commands like
`python -m yamllint`. But some environments (like continuous integration
of Debian or CentOS) don't always include the `python` executable (they
use `python3` instead).
Let's dynamically detect the Python executable path.
Some operating systems don't have the `C.UTF-8` locale installed yet
(for instance, CentOS 7). In such a case, fallback to `en_US.UTF-8` so
that tests can be run.
This follows commit 92ff315.
If a key-value pair follows an empty list, i.e.:
```yaml
a:
-
b: c
```
yamllint will complain:
```
warning wrong indentation: expected 2 but found 0 (indentation)
```
This is because it is expecting the second key to be a continuation of
the block entry above:
```yaml
a:
-
b: c
```
However, both are perfectly valid, though structurally different.
Example of configuration to use this feature:
# For all rules
ignore: |
*.dont-lint-me.yaml
/bin/
!/bin/*.lint-me-anyway.yaml
rules:
key-duplicates:
ignore: |
generated
*.template.yaml
trailing-spaces:
ignore: |
*.ignore-trailing-spaces.yaml
/ascii-art/*
Closes#43.
In the case when the conf is as follows:
indentation:
spaces: consistent
indent-sequences: true
and there is no indented block before the first block sequence, and this
block sequence is not indented, then the spaces number is computed as
zero (while it obviously shouldn't be).
This causes such a document to fail on 4th line, instead of 2nd:
a:
- b
c:
- d
This commit fixes that, and adds corresponding tests.
Fixes: #39
Although `yes` and `no` are recognized as booleans by the pyyaml parser,
the correct keywords are `true` and `false` (as highlighted by the newly
added `truthy` rule).
This commit replaces the use of `yes`/`no` by `true`/`false` and
advertise it in the docs, but also makes sure this change is
backward-compatible (so that `yes` and `no` still work).
This change fixes new errors detected by the last version of pycodestyle
(2.2.0), which is a dependency of flake8:
./tests/test_spec_examples.py:51:1: E305 expected 2 blank lines
after class or function definition, found 1
./tests/test_spec_examples.py:139:1: E305 expected 2 blank lines
after class or function definition, found 1
See pycodestyle changelog at 2.2.0 and
https://github.com/PyCQA/pycodestyle/pull/593.
With this change, we don't require quotes for truthy values that are
explicitly typed. For instance, the following examples are all
considered valid:
string1: !!str True
string2: !!str yes
string3: !!str off
encoded: !!binary |
True
OFF
pad== # this decodes as 'N\xbb\x9e8Qii'
boolean1: !!bool true
boolean2: !!bool "false"
boolean3: !!bool FALSE
boolean4: !!bool True
boolean5: !!bool off
boolean6: !!bool NO
With `allow-non-breakable-inline-mappings` enabled, every long line is
passed through `loader.peek_token()`. Even lines that are not valid
YAML. For this reason, this code must be wrapped in a `try`/`except`
block.
Closes: #21
This commit extracts the inline mappings logic defined in the previous
commit to a separate config option, as suggested by @adrienverge. I'll
squash this into the previous commit if the change is accepted. (I named
the option slightly differently to what was suggested as I think my
proposal reads better without consulting the docs: I'd be happy to
reconsider this.)
This change make the `comments` rule accept comments that start with
multiple pound signs, e.g.:
##############################
## This is some documentation
Closes: #12
When piping yamllint output to a file, "coloured" characters aren't
interpreted and pollute text formatting with glyphs like:
�[4m./global.yaml�[0m
�[2m1439:52�[0m �[31merror�[0m no new line character...
With this commit, stdout is checked: if it's a TTY then output is
coloured, otherwise output is simple text.
Closes: #14
grzesuav
Adrien Vergé
Ondrej Vaško
Miguel Barao
Mattias Bengtsson
Hugo
sedrubal
Guido Wischrop (mgm tp)
Nick Burke
xieenlong
Greg Dubicki
Johannes F. Knauf
Tim Wade
Jim Riggs
Jonathan Sokolowski
Peter Ericson
Allan Lewis
Allan Lewis