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']`.
Edit documentation for the `truthy` rule, in order to:
- add quotes to examples (`'yes'` instead of `yes`) to avoid
misconfigurations,
- group truthy values in the `allowed-values` option paragraph, for
easier reading.
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
The `pkg_resources` package inside `setuptools` explicitly [disallows
Python 3.3](7392f01ffc (diff-81de4a30a55fcc3fb944f8387ea9ec94)):
if (3, 0) < sys.version_info < (3, 4):
raise RuntimeError("Python 3.4 or later is required")
It's time to drop support for 3.3.
`-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.
Because installing dependencies for `coveralls` now fails with:
Collecting pycparser (from cffi>=1.7->cryptography>=1.3.4; python_version <= "2.7" and extra == "secure"->urllib3[secure]; python_version < "3"->coveralls)
[...]
pycparser requires Python '>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*' but the running Python is 2.6.9
There is a backwards-incompatible change in PyYAML that induces a crash
if `check_token()` is not called before `peek_token()`. See commit
a02d17a in PyYAML or https://github.com/yaml/pyyaml/pull/150.
Closes#105.
