According to the YAML specification [^1]:
- > An anchored node need not be referenced by any alias nodes
This means that it's OK to declare anchors but don't have any alias
referencing them. However users could want to avoid this, so a new
option (e.g. `forbid-unused-anchors`) is implemented in this change.
It is disabled by default.
[^1]: https://yaml.org/spec/1.2.2/#692-node-anchors
In the rare case when the key before `:` is an alias (e.g. `{*x : 4}`),
the space before `:` is required (although this requirement is not
enforced by PyYAML), the reason being that a colon can be part of an
anchor name. Consequently, this commit adapts the `colons` rule to avoid
failures when this happens.
See this comment from Tina Müller for more details:
https://github.com/adrienverge/yamllint/pull/550#discussion_r1155297373
Although accepted by PyYAML, `{*x: 4}` is not valid YAML: it should be
noted `{*x : 4}`. The reason is that a colon can be part of an anchor
name. See this comment from Tina Müller for more details:
https://github.com/adrienverge/yamllint/pull/550#discussion_r1155297373
Even if it's not a problem for yamllint, let's fix our tests to include
valid YAML snippets.
According to the YAML specification [^1]:
- > It is an error for an alias node to use an anchor that does not
> previously occur in the document.
The `forbid-undeclared-aliases` option checks that aliases do have a
matching anchor declared previously in the document. Since this is
required by the YAML spec, this option is enabled by default.
- > The alias refers to the most recent preceding node having the same
> anchor.
This means that having a same anchor repeated in a document is
allowed. However users could want to avoid this, so the new option
`forbid-duplicated-anchors` allows that. It's disabled by default.
- > It is not an error to specify an anchor that is not used by any
> alias node.
This means that it's OK to declare anchors but don't have any alias
referencing them. However users could want to avoid this, so a new
option (e.g. `forbid-unused-anchors`) could be implemented in the
future. See https://github.com/adrienverge/yamllint/pull/537.
Fixes#395Closes#420
[^1]: https://yaml.org/spec/1.2.2/#71-alias-nodes
When {spaces: consistent, indent-sequences: true} (the defaults),
and the expected indent for a block sequence that should be indented
is unknown, set the expected indent to an unknown value (-1) rather
than an arbitrary one (2). This ensures wrong-indentation is properly
caught when block sequences are nested.
Fixes issue #485
The rule correctly reports number values like `.1`, `1e2`, `.NaN` and
`.Inf`, but it also reported false positives on strings like `.1two3`,
`1e2a`, `.NaNa` and `.Infinit∞`.
The regexps need to end with an end delimiter (`$`) otherwise longer
strings can be matched too.
Fixes https://github.com/adrienverge/yamllint/issues/495
Commit c268a82 "key-duplicates: Don't crash on redundant closing
brackets or braces" fixed a problem but introduced another one: it
crashes on systems with (I guess) an old version of PyYAML. This is
probably linked to the "Allow colon in a plain scalar in a flow context"
issue on PyYAML [1].
For example, this problem happens on CentOS 8:
FAIL: test_disabled (tests.rules.test_key_duplicates.KeyDuplicatesTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "…/tests/rules/test_key_duplicates.py", line 90, in test_disabled
'{a:1, b:2}}\n', conf, problem=(2, 11, 'syntax'))
File "…/tests/common.py", line 54, in check
self.assertEqual(real_problems, expected_problems)
AssertionError: Lists differ: …
- [2:3: syntax error: found unexpected ':' (syntax)]
+ [2:11: <no description>]
I propose to simply fix the *space following a colon* problem, since
it's not related to what the original author @tamere-allo-peter tried to
fix.
[1]: https://github.com/yaml/pyyaml/pull/45
- Add a `temp_workspace` context manager to simplify writing new tests.
- Add `# pragma: no cover` to unit test code paths used for skipping tests.
These code paths are only covered when tests are skipped.
That makes it impractical to reach full code coverage on the unit test code.
Having full coverage of unit tests is helpful for identifying unused tests.
- Test the `octal-values` rule with a custom tag.
- Test the cli `-d` option with the `default` config.
- Test support for the `XDG_CONFIG_HOME` env var.
- Test warning message output.
- Test support for `.yamllint.yml` config files.
- Test support for `.yamllint.yaml` config files.
- Test error handling of a rule with a non-enable|disable|dict value.
- Test error handling of `ignore` with a non-pattern value.
- Test error handling of a rule `ignore` with a non-pattern value.
- Test error handling of `locale` with a non-string value.
- Test error handling of `yaml-files` with a non-list value.
- Test extending config containing `ignore`.
- Test `LintProblem.__repr__` without a rule.
- Test `LintProblem.__repr__` with a rule.
The `# -*- coding: utf-8 -*-` headers were useful for Python 2, and
aren't needed for Python 3 where UTF-8 is the default.
yamllint support of Python 2 was dropped in early 2021, see commit
a3fc64d "End support for Python 2".
Let's drop these headers.
Basically, any character is now allowed after the shebang marker.
Closes#428.
Whitespace after the #! marker on shebang lines is authorized and
optional, as explained on Wikipedia's entry for shebang line as can be
seen from the extracts below :
> White space after #! is optional
and
> It has been claimed[20] that some old versions of Unix expect the
> normal shebang to be followed by a space and a slash (#! /), but this
> appears to be untrue;[21] rather, blanks after the shebang have
> traditionally been allowed, and sometimes documented with a space
PyYAML implements YAML spec version 1.1, not 1.2. Hence, values starting
with `0o` are not considered as numbers: they are just strings, so they
need quotes when `quoted-strings: {required: true}`.
>>> import yaml
>>> yaml.resolver.Resolver().resolve(yaml.nodes.ScalarNode, '100', (True, False))
'tag:yaml.org,2002:int'
>>> yaml.resolver.Resolver().resolve(yaml.nodes.ScalarNode, '0100', (True, False))
'tag:yaml.org,2002:int'
>>> yaml.resolver.Resolver().resolve(yaml.nodes.ScalarNode, '0o100', (True, False))
'tag:yaml.org,2002:str'
Let's try to prevent that.
Fixes https://github.com/adrienverge/yamllint/issues/351.
We'd like to disallow brackets and braces in our YAML, but there's a
catch: the only way to describe an empty array or hash in YAML is to
supply an empty one (`[]` or `{}`). Otherwise, the value will be null.
This commit adds a `non-empty` option to `forbid` for brackets and
braces. When it is set, all flow and sequence mappings will cause errors
_except_ for empty ones.
Add 'forbid' configuration parameters to the braces and brackets rules
to allow users to forbid the use of flow style collections, flow
mappings and flow sequences.
Pound-signs followed by a lone CRLF should not
raise if require-starting-space is specified.
If require-starting-space is true, *and* either:
- new-lines: disbale, or
- newlines: type: dos
is specified, a line with `#\r` or `#\r\n` should
not raise a false positive.
This commit also uses a Set for O(1) membership testing
and uses the correct escape sequence for the nul byte.
If we find a CRLF when looking for Unix newlines, yamllint
should always raise, regardless of logic with
require-starting-space.
Closes: Issue #171.
Add ability to:
- require strings to be quoted if they match a pattern (PCRE regex)
- allow quoted strings if they match a pattern, while `require:
only-when-needed` is enforced.
Co-Authored-By: Leo Feyer (https://github.com/adrienverge/yamllint/pull/246)
The rule worked for values like:
flow-map: {a: foo, b: "bar"}
block-map:
a: foo
b: "bar"
But not for:
flow-seq: [foo, "bar"]
block-seq:
- foo
- "bar"
Also add tests to make sure there will be no regression.
Fixes: #208.
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.
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
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.
amimas
Adrien Vergé
Dimitri Papadopoulos
Brian Brookman
Roman Geraskin
Derek Brown
Jan Wille
Matt Clay
Jérôme Alet
Andrew Imeson
Patryk Małek
Rusty Geldmacher
Satoru SATOH
Julien Falque
Wolfgang Walther
Brad Solomon
ilyam8
Rui Pinge
Rui Pinge
Imran Iqbal
Ondrej Vaško
Mattias Bengtsson
Hugo
Guido Wischrop (mgm tp)